CWE-359
AllowedExposure of Private Personal Information to an Unauthorized Actor
Abstraction: Base · Status: Incomplete
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.
331 vulnerabilities reference this CWE, most recent first.
GHSA-7PGW-Q3QP-6PGQ
Vulnerability from github – Published: 2025-07-10 13:10 – Updated: 2025-07-10 23:23Summary
Several #dpl parameters can leak usernames that have been hidden using revision deletion, suppression, or the hideuser block flag.
Details
The parameters adduser, addauthor, and addlasteditor output the page creator or last editor using the %USER% placeholder. These display the actual username, even when that name has been hidden using revision deletion, suppression (oversight), or hideuser.
The %CONTRIBUTOR% placeholder, used with addcontribution, behaves similarly and also reveals hidden usernames.
In addition, the following parameters can expose suppressed usernames when combined with %USER% or similar output placeholders:
- lastrevisionbefore
- allrevisionsbefore
- firstrevisionsince
- allrevisionssince
These parameters reference specific revisions and allow output of user-related metadata. If a username has been hidden from those revisions, it may still appear in the output.
Further, the parameters createdby, notcreatedby, modifiedby, notmodifiedby, lastmodifiedby, and notlastmodifiedby accept usernames as input. When the correct (suppressed) username is used, the query may return matching pages or edits. This can reveal the presence and association of a hidden identity, even if not displayed directly. However, this is a more indirect exposure than the output parameters mentioned above.
Proof of Concept
- Create a page while logged in as a user.
- Revision delete or suppress the username from the page history.
- Use a DPL query with one of the affected parameters.
- The output reveals the hidden username.
Example
The following query reveals the suppressed username Example user:
{{#dpl:
| title = File:Example.png
| addauthor = true
| format = ,%USER%,,
}}
Similar behavior occurs using parameters like lastrevisionbefore with %USER% in the format string.
Impact
This issue causes the exposure of usernames that were intentionally hidden by administrators. It directly undermines revision deletion, user suppression, and block-related privacy measures. In some cases, usernames can be revealed both directly through output and indirectly through query behavior.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "universal-omega/dynamic-page-list3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53625"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-10T13:10:20Z",
"nvd_published_at": "2025-07-10T19:15:26Z",
"severity": "HIGH"
},
"details": "### Summary\nSeveral `#dpl` parameters can leak usernames that have been hidden using revision deletion, suppression, or the `hideuser` block flag.\n\n### Details\nThe parameters `adduser`, `addauthor`, and `addlasteditor` output the page creator or last editor using the `%USER%` placeholder. These display the actual username, even when that name has been hidden using revision deletion, suppression (oversight), or `hideuser`.\n\nThe `%CONTRIBUTOR%` placeholder, used with `addcontribution`, behaves similarly and also reveals hidden usernames.\n\nIn addition, the following parameters can expose suppressed usernames when combined with `%USER%` or similar output placeholders:\n- `lastrevisionbefore`\n- `allrevisionsbefore`\n- `firstrevisionsince`\n- `allrevisionssince`\n\nThese parameters reference specific revisions and allow output of user-related metadata. If a username has been hidden from those revisions, it may still appear in the output.\n\nFurther, the parameters `createdby`, `notcreatedby`, `modifiedby`, `notmodifiedby`, `lastmodifiedby`, and `notlastmodifiedby` accept usernames as input. When the correct (suppressed) username is used, the query may return matching pages or edits. This can reveal the presence and association of a hidden identity, even if not displayed directly. However, this is a more indirect exposure than the output parameters mentioned above.\n\n### Proof of Concept\n\n1. Create a page while logged in as a user.\n2. Revision delete or suppress the username from the page history.\n3. Use a DPL query with one of the affected parameters.\n4. The output reveals the hidden username.\n\n#### Example\n\nThe following query reveals the suppressed username `Example user`:\n\n```wikitext\n{{#dpl:\n| title = File:Example.png\n| addauthor = true\n| format = ,%USER%,,\n}}\n```\n\nSimilar behavior occurs using parameters like `lastrevisionbefore` with `%USER%` in the `format` string.\n\n### Impact\nThis issue causes the exposure of usernames that were intentionally hidden by administrators. It directly undermines revision deletion, user suppression, and block-related privacy measures. In some cases, usernames can be revealed both directly through output and indirectly through query behavior.",
"id": "GHSA-7pgw-q3qp-6pgq",
"modified": "2025-07-10T23:23:34Z",
"published": "2025-07-10T13:10:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Universal-Omega/DynamicPageList3/security/advisories/GHSA-7pgw-q3qp-6pgq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53625"
},
{
"type": "WEB",
"url": "https://github.com/Universal-Omega/DynamicPageList3/commit/a3dae0c89fb4214390c29ceffa23bbe2099986d6"
},
{
"type": "PACKAGE",
"url": "https://github.com/Universal-Omega/DynamicPageList3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "DynamicPageList3 vulnerability exposes hidden/suppressed usernames"
}
GHSA-7XJX-FWH6-G2VQ
Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-11-05 21:31A privacy issue was addressed by removing sensitive data. This issue is fixed in iOS 26.1 and iPadOS 26.1, visionOS 26.1. An app may be able to fingerprint the user.
{
"affected": [],
"aliases": [
"CVE-2025-43439"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T02:15:49Z",
"severity": "HIGH"
},
"details": "A privacy issue was addressed by removing sensitive data. This issue is fixed in iOS 26.1 and iPadOS 26.1, visionOS 26.1. An app may be able to fingerprint the user.",
"id": "GHSA-7xjx-fwh6-g2vq",
"modified": "2025-11-05T21:31:00Z",
"published": "2025-11-04T03:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43439"
},
{
"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/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-7XQ4-MWCP-Q8FX
Vulnerability from github – Published: 2025-12-26 06:30 – Updated: 2025-12-26 19:36In Gitea before 1.21.2, an anonymous user can visit a private user's project.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.21.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68945"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-26T19:36:13Z",
"nvd_published_at": "2025-12-26T04:15:41Z",
"severity": "MODERATE"
},
"details": "In Gitea before 1.21.2, an anonymous user can visit a private user\u0027s project.",
"id": "GHSA-7xq4-mwcp-q8fx",
"modified": "2025-12-26T19:36:13Z",
"published": "2025-12-26T06:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68945"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/28423"
},
{
"type": "WEB",
"url": "https://blog.gitea.com/release-of-1.21.2"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.21.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea: anonymous user can visit private user\u0027s project"
}
GHSA-829C-JPVX-VFRV
Vulnerability from github – Published: 2025-12-19 09:30 – Updated: 2026-02-23 12:31An information disclosure vulnerability in M-Files Server before versions 25.12.15491.7, 25.8 LTS SR3, 25.2 LTS SR3 and 24.8 LTS SR5 allows an authenticated attacker using M-Files Web to capture session tokens of other active users.
{
"affected": [],
"aliases": [
"CVE-2025-13008"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-19T07:15:58Z",
"severity": "HIGH"
},
"details": "An information disclosure vulnerability in M-Files Server before versions 25.12.15491.7, 25.8 LTS SR3, 25.2 LTS SR3 and 24.8 LTS SR5 allows an authenticated attacker using M-Files Web to capture session tokens of other active users.",
"id": "GHSA-829c-jpvx-vfrv",
"modified": "2026-02-23T12:31:29Z",
"published": "2025-12-19T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13008"
},
{
"type": "WEB",
"url": "https://empower.m-files.com/security-advisories/CVE-2025-13008"
},
{
"type": "WEB",
"url": "https://product.m-files.com/security-advisories/cve-2025-13008"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/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-85Q6-Q3JC-QVMC
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12Acrobat Reader DC versions versions 2021.001.20150 (and earlier), 2020.001.30020 (and earlier) and 2017.011.30194 (and earlier) are affected by an Information Exposure vulnerability. An unauthenticated attacker could leverage this vulnerability to get access to restricted data stored within global variables and objects.
{
"affected": [],
"aliases": [
"CVE-2021-28559"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-02T17:15:00Z",
"severity": "MODERATE"
},
"details": "Acrobat Reader DC versions versions 2021.001.20150 (and earlier), 2020.001.30020 (and earlier) and 2017.011.30194 (and earlier) are affected by an Information Exposure vulnerability. An unauthenticated attacker could leverage this vulnerability to get access to restricted data stored within global variables and objects.",
"id": "GHSA-85q6-q3jc-qvmc",
"modified": "2022-05-24T19:12:52Z",
"published": "2022-05-24T19:12:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28559"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/acrobat/apsb21-29.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-868X-MJ3Q-C3W4
Vulnerability from github – Published: 2024-06-19 21:32 – Updated: 2024-07-03 18:46In the module "Login as customer PRO" (loginascustomerpro) <1.2.7 from Weblir for PrestaShop, a guest can access direct link to connect to each customer account of the Shop if the module is not installed OR if a secret accessible to administrator is stolen.
{
"affected": [],
"aliases": [
"CVE-2024-36677"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T21:15:57Z",
"severity": "HIGH"
},
"details": "In the module \"Login as customer PRO\" (loginascustomerpro) \u003c1.2.7 from Weblir for PrestaShop, a guest can access direct link to connect to each customer account of the Shop if the module is not installed OR if a secret accessible to administrator is stolen.",
"id": "GHSA-868x-mj3q-c3w4",
"modified": "2024-07-03T18:46:03Z",
"published": "2024-06-19T21:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36677"
},
{
"type": "WEB",
"url": "https://security.friendsofpresta.org/modules/2024/06/18/loginascustomerpro.html"
}
],
"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-8G9C-C9CM-9C56
Vulnerability from github – Published: 2023-06-20 16:46 – Updated: 2023-06-20 16:46Impact
Any user can call a REST endpoint and obtain the obfuscated passwords (even when the mail obfuscation is activated).
For instance, by calling http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/U1/objects/XWiki.XWikiUsers/0 when user U1 exists on wiki xwiki.
Patches
The issue has been patched on XWiki 14.4.8, 14.10.6, and 15.1
Workarounds
There is no known workaround. It is advised to upgrade to one of the patched versions.
References
- https://jira.xwiki.org/browse/XWIKI-16138
- https://github.com/xwiki/xwiki-platform/commit/824cd742ecf5439971247da11bfe7e0ad2b10ede
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
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-rest-server"
},
"ranges": [
{
"events": [
{
"introduced": "7.3-milestone-1"
},
{
"fixed": "14.4.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-rest-server"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-rest-server"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-35151"
],
"database_specific": {
"cwe_ids": [
"CWE-359",
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-20T16:46:29Z",
"nvd_published_at": "2023-06-23T17:15:09Z",
"severity": "HIGH"
},
"details": "### Impact\nAny user can call a REST endpoint and obtain the obfuscated passwords (even when the mail obfuscation is activated).\n\nFor instance, by calling http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/U1/objects/XWiki.XWikiUsers/0 when user `U1` exists on wiki `xwiki`.\n\n### Patches\nThe issue has been patched on XWiki 14.4.8, 14.10.6, and 15.1 \n\n### Workarounds\nThere is no known workaround. It is advised to upgrade to one of the patched versions.\n\n### References\n- https://jira.xwiki.org/browse/XWIKI-16138\n- https://github.com/xwiki/xwiki-platform/commit/824cd742ecf5439971247da11bfe7e0ad2b10ede\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",
"id": "GHSA-8g9c-c9cm-9c56",
"modified": "2023-06-20T16:46:29Z",
"published": "2023-06-20T16:46:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-8g9c-c9cm-9c56"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35151"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/824cd742ecf5439971247da11bfe7e0ad2b10ede"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-16138"
}
],
"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"
}
],
"summary": "XWiki Platform may show email addresses in clear in REST results"
}
GHSA-8QFF-6GWC-WPH3
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32An information disclosure vulnerability exists in the latest version of transformeroptimus/superagi. An attacker can leak sensitive user information, including names, emails, and passwords, by attempting to register a new account with an email that is already in use. The server returns all information associated with the existing account. The vulnerable endpoint is located in the user registration functionality.
{
"affected": [],
"aliases": [
"CVE-2024-10267"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:15Z",
"severity": "HIGH"
},
"details": "An information disclosure vulnerability exists in the latest version of transformeroptimus/superagi. An attacker can leak sensitive user information, including names, emails, and passwords, by attempting to register a new account with an email that is already in use. The server returns all information associated with the existing account. The vulnerable endpoint is located in the user registration functionality.",
"id": "GHSA-8qff-6gwc-wph3",
"modified": "2025-03-20T12:32:39Z",
"published": "2025-03-20T12:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10267"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/13da8366-4670-4d46-9f5a-ba3f642b692e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8R7F-R8HJ-R3RV
Vulnerability from github – Published: 2026-07-24 20:46 – Updated: 2026-07-24 20:46Summary
GET /api/v4/user/search is available to any logged-in user. The service calls userClient.SearchActive, but despite its name that method filters only by email/nickname keyword and never adds a StatusActive predicate — while the sibling lookups GetActiveByID and GetActiveByDavAccount, defined a few lines above it, do. Search hits are serialized at RedactLevelUser, which includes the email address.
A normal logged-in user can therefore enumerate and retrieve the email (plus nickname, avatar, creation time, redacted group, profile share-visibility) of inactive and banned accounts that an active-user directory is supposed to suppress. No global status interceptor compensates — the only User query interceptor is soft-delete, and inactive/banned rows are not soft-deleted.
Details
Root cause (verified at 26b6b10)
1. Route — logged-in + UserInfo.Read scope (routers/router.go):
user := v4.Group("user") // protected user group (login required)
user.GET("search",
middleware.RequiredScopes(types.ScopeUserInfoRead),
controllers.FromQuery[usersvc.SearchUserService](...), controllers.UserSearch)
The RequiredScopes check applies to scoped OAuth tokens; plain session requests are not gated by it — so any logged-in user reaches the search.
2. Service — 2-char keyword to SearchActive (service/user/info.go):
type SearchUserService struct { Keyword string `form:"keyword" binding:"required,min=2"` }
const resultLimit = 10
func (s *SearchUserService) Search(c *gin.Context) ([]*ent.User, error) {
return dep.UserClient().SearchActive(c, resultLimit, s.Keyword)
}
3. The bug — SearchActive has no status predicate (inventory/user.go):
func (c *userClient) SearchActive(ctx context.Context, limit int, keyword string) ([]*ent.User, error) {
ctx = context.WithValue(ctx, LoadUserGroup{}, true)
return withUserEagerLoading(ctx,
c.client.User.Query().
Where(user.Or(user.EmailContainsFold(keyword), user.NickContainsFold(keyword))).
Limit(limit), // <-- no user.StatusEQ(user.StatusActive)
).All(ctx)
}
Contrast the siblings immediately above:
func (c *userClient) GetActiveByID(...) { ... Where(user.ID(id)).Where(user.StatusEQ(user.StatusActive)) ... }
func (c *userClient) GetActiveByDavAccount(...) { ... Where(user.EmailEqualFold(email)).Where(user.StatusEQ(user.StatusActive)) ... }
withUserEagerLoading only eager-loads the group/passkey edges; it adds no status filter. Status values are active/inactive/manual_banned/sys_banned (ent/user/user.go).
4. No global status interceptor — User.Mixin() is CommonMixin{} (ent/schema/user.go), whose Interceptors() returns only softDeleteInterceptors (ent/schema/common.go). Inactive/banned users are not soft-deleted, so nothing filters them out at query time.
5. Results serialized with email (routers/controllers/user.go → service/user/response.go):
// UserSearch:
return user.BuildUserRedacted(item, user.RedactLevelUser, hasher)
// BuildUserRedacted:
if level == RedactLevelUser { user.Email = userRaw.Email } // email included
Secondary path: GET /api/v4/user/info/:id → GetUser uses GetByID (no status filter), and the controller picks RedactLevelUser for any non-anonymous caller (RedactLevelAnonymous only for anonymous). So a logged-in caller with an inactive/banned user's hashed ID also receives the email-bearing profile. (Less practical than search, since it needs the hashed ID rather than a 2-char keyword.)
Steps to reproduce (requires a live instance)
- Ensure a target account exists in
inactiveormanual_banned/sys_bannedstatus (e.g., an unconfirmed registration or a banned user). - As any logged-in user:
GET /api/v4/user/search?keyword=<>=2 chars of the target email/nick> Cookie: cloudreve-session=<attacker-session> - Observe the inactive/banned account in the results, including its
email. Expected: only active accounts appear (matching the method name and the siblingGetActive*behavior). Actual: inactive/banned accounts are returned with their email addresses.
Impact
Any logged-in user can enumerate and harvest the email addresses (and basic profile metadata) of inactive and banned accounts that active-user lookups intentionally hide. No account access, passwords, or 2FA secrets are exposed; the impact is PII leakage and user enumeration.
Remediation
- Add
Where(user.StatusEQ(user.StatusActive))toSearchActive(matchingGetActiveByID). - Apply the same active-status requirement to
GET /api/v4/user/info/:id, or fall back to anonymous-level redaction unless the target account is active. - Consider not returning email from directory search at all — display name + hashed ID is usually sufficient.
- Regression tests: searching a keyword that matches an inactive/banned account must return no result (or no email).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0-20260613023921-7e1289d55279"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.0.0-20250225100611-da4e44b77af4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55496"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-359"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T20:46:49Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n \n`GET /api/v4/user/search` is available to any logged-in user. The service calls `userClient.SearchActive`, but despite its name that method filters only by email/nickname keyword and **never adds a `StatusActive` predicate** \u2014 while the sibling lookups `GetActiveByID` and `GetActiveByDavAccount`, defined a few lines above it, do. Search hits are serialized at `RedactLevelUser`, which includes the email address.\n \nA normal logged-in user can therefore enumerate and retrieve the email (plus nickname, avatar, creation time, redacted group, profile share-visibility) of **inactive and banned** accounts that an active-user directory is supposed to suppress. No global status interceptor compensates \u2014 the only User query interceptor is soft-delete, and inactive/banned rows are not soft-deleted.\n\n### Details\n## Root cause (verified at `26b6b10`)\n \n**1. Route \u2014 logged-in + `UserInfo.Read` scope** (`routers/router.go`):\n```go\nuser := v4.Group(\"user\") // protected user group (login required)\nuser.GET(\"search\",\n middleware.RequiredScopes(types.ScopeUserInfoRead),\n controllers.FromQuery[usersvc.SearchUserService](...), controllers.UserSearch)\n```\nThe `RequiredScopes` check applies to scoped OAuth tokens; plain session requests are not gated by it \u2014 so any logged-in user reaches the search.\n \n**2. Service \u2014 2-char keyword to `SearchActive`** (`service/user/info.go`):\n```go\ntype SearchUserService struct { Keyword string `form:\"keyword\" binding:\"required,min=2\"` }\nconst resultLimit = 10\nfunc (s *SearchUserService) Search(c *gin.Context) ([]*ent.User, error) {\n return dep.UserClient().SearchActive(c, resultLimit, s.Keyword)\n}\n```\n \n**3. The bug \u2014 `SearchActive` has no status predicate** (`inventory/user.go`):\n```go\nfunc (c *userClient) SearchActive(ctx context.Context, limit int, keyword string) ([]*ent.User, error) {\n ctx = context.WithValue(ctx, LoadUserGroup{}, true)\n return withUserEagerLoading(ctx,\n c.client.User.Query().\n Where(user.Or(user.EmailContainsFold(keyword), user.NickContainsFold(keyword))).\n Limit(limit), // \u003c-- no user.StatusEQ(user.StatusActive)\n ).All(ctx)\n}\n```\nContrast the siblings immediately above:\n```go\nfunc (c *userClient) GetActiveByID(...) { ... Where(user.ID(id)).Where(user.StatusEQ(user.StatusActive)) ... }\nfunc (c *userClient) GetActiveByDavAccount(...) { ... Where(user.EmailEqualFold(email)).Where(user.StatusEQ(user.StatusActive)) ... }\n```\n`withUserEagerLoading` only eager-loads the group/passkey edges; it adds no status filter. Status values are `active`/`inactive`/`manual_banned`/`sys_banned` (`ent/user/user.go`).\n \n**4. No global status interceptor** \u2014 `User.Mixin()` is `CommonMixin{}` (`ent/schema/user.go`), whose `Interceptors()` returns only `softDeleteInterceptors` (`ent/schema/common.go`). Inactive/banned users are not soft-deleted, so nothing filters them out at query time.\n \n**5. Results serialized with email** (`routers/controllers/user.go` \u2192 `service/user/response.go`):\n```go\n// UserSearch:\nreturn user.BuildUserRedacted(item, user.RedactLevelUser, hasher)\n// BuildUserRedacted:\nif level == RedactLevelUser { user.Email = userRaw.Email } // email included\n```\n \n**Secondary path:** `GET /api/v4/user/info/:id` \u2192 `GetUser` uses `GetByID` (no status filter), and the controller picks `RedactLevelUser` for any non-anonymous caller (`RedactLevelAnonymous` only for anonymous). So a logged-in caller with an inactive/banned user\u0027s hashed ID also receives the email-bearing profile. (Less practical than search, since it needs the hashed ID rather than a 2-char keyword.)\n\n## Steps to reproduce (requires a live instance)\n \n1. Ensure a target account exists in `inactive` or `manual_banned`/`sys_banned` status (e.g., an unconfirmed registration or a banned user).\n2. As any logged-in user:\n ```\n GET /api/v4/user/search?keyword=\u003c\u003e=2 chars of the target email/nick\u003e\n Cookie: cloudreve-session=\u003cattacker-session\u003e\n ```\n3. Observe the inactive/banned account in the results, including its `email`.\n**Expected:** only active accounts appear (matching the method name and the sibling `GetActive*` behavior).\n**Actual:** inactive/banned accounts are returned with their email addresses.\n \n## Impact\n \nAny logged-in user can enumerate and harvest the email addresses (and basic profile metadata) of inactive and banned accounts that active-user lookups intentionally hide. No account access, passwords, or 2FA secrets are exposed; the impact is PII leakage and user enumeration.\n \n## Remediation\n \n- Add `Where(user.StatusEQ(user.StatusActive))` to `SearchActive` (matching `GetActiveByID`).\n- Apply the same active-status requirement to `GET /api/v4/user/info/:id`, or fall back to anonymous-level redaction unless the target account is active.\n- Consider not returning email from directory search at all \u2014 display name + hashed ID is usually sufficient.\n- Regression tests: searching a keyword that matches an inactive/banned account must return no result (or no email).",
"id": "GHSA-8r7f-r8hj-r3rv",
"modified": "2026-07-24T20:46:49Z",
"published": "2026-07-24T20:46:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-8r7f-r8hj-r3rv"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/commit/7e1289d552794bdbeb551be78456115c87dcb3da"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudreve/cloudreve"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/releases/tag/4.17.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": "Cloudreve: Information Exposure in `GET /api/v4/user/search`: `SearchActive` omits the active-status predicate, leaking inactive/banned account emails"
}
GHSA-8WGP-QQW5-PMFC
Vulnerability from github – Published: 2025-09-16 00:30 – Updated: 2025-11-03 21:34A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Tahoe 26. An app may be able to access user-sensitive data.
{
"affected": [],
"aliases": [
"CVE-2025-43279"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T23:15:31Z",
"severity": "MODERATE"
},
"details": "A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Tahoe 26. An app may be able to access user-sensitive data.",
"id": "GHSA-8wgp-qqw5-pmfc",
"modified": "2025-11-03T21:34:28Z",
"published": "2025-09-16T00:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43279"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125110"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/53"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
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
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
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.