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.
335 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-8XX5-H6M3-JR33
Vulnerability from github – Published: 2025-09-04 20:01 – Updated: 2025-09-10 21:02Impact
An unauthenticated attacker with access to the back-office URL can manipulate the id_employee and reset_token parameters to enumerate valid back-office employee email addresses.
Impacted parties: Store administrators and employees: their email addresses are exposed. Merchants: risk of phishing, social engineering, and brute-force attacks targeting admin accounts.
Patches
PrestaShop 8.2.3
Workarounds
You must upgrade, or at least apply the changes from the PrestaShop 8.2.3 patch. More information: https://build.prestashop-project.org/news/2025/prestashop-8-2-3-security-release/
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "prestashop/prestashop"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.2.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-51586"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-359"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-04T20:01:00Z",
"nvd_published_at": "2025-09-08T17:15:33Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn unauthenticated attacker with access to the back-office URL can manipulate the id_employee and reset_token parameters to enumerate valid back-office employee email addresses.\n\nImpacted parties:\nStore administrators and employees: their email addresses are exposed.\nMerchants: risk of phishing, social engineering, and brute-force attacks targeting admin accounts.\n\n### Patches\nPrestaShop 8.2.3\n\n### Workarounds\nYou must upgrade, or at least apply the changes from the PrestaShop 8.2.3 patch. More information: https://build.prestashop-project.org/news/2025/prestashop-8-2-3-security-release/",
"id": "GHSA-8xx5-h6m3-jr33",
"modified": "2025-09-10T21:02:35Z",
"published": "2025-09-04T20:01:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/PrestaShop/PrestaShop/security/advisories/GHSA-8xx5-h6m3-jr33"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-51586"
},
{
"type": "WEB",
"url": "https://github.com/PrestaShop/PrestaShop/commit/c97bdf10f77fedbe5a61a1dec5f96b3abb1d76fb"
},
{
"type": "WEB",
"url": "https://build.prestashop-project.org/news/2025/prestashop-8-2-3-security-release"
},
{
"type": "PACKAGE",
"url": "https://github.com/PrestaShop/PrestaShop"
},
{
"type": "WEB",
"url": "https://github.com/PrestaShop/PrestaShop/releases/tag/8.2.1"
},
{
"type": "WEB",
"url": "https://github.com/PrestaShop/PrestaShop/releases/tag/8.2.3"
},
{
"type": "WEB",
"url": "https://maxime-morel.github.io/advisories/2025/CVE-2025-51586.md"
},
{
"type": "WEB",
"url": "https://prestashop.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Presta Shop vulnerable to email enumeration "
}
GHSA-95R2-976X-QJFH
Vulnerability from github – Published: 2025-10-08 18:30 – Updated: 2025-10-08 18:30In Gemini iOS, when a user shared a snippet of a conversation, it would share the entire conversation via a sharable public link that contained the entire conversation history and not just the snippet.
{
"affected": [],
"aliases": [
"CVE-2025-5009"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-08T16:15:39Z",
"severity": "LOW"
},
"details": "In Gemini iOS, when a user shared a snippet of a conversation, it would share the entire conversation via a sharable public link that contained the entire conversation history and not just the snippet.",
"id": "GHSA-95r2-976x-qjfh",
"modified": "2025-10-08T18:30:16Z",
"published": "2025-10-08T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5009"
},
{
"type": "WEB",
"url": "https://medium.com/@warisjeet31/google-gemini-ios-vulnerability-public-link-sharing-silently-leaks-entire-conversations-e1f80cbea25c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:H/UI:A/VC:L/VI:N/VA:N/SC:L/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-96P6-Q6GP-F474
Vulnerability from github – Published: 2022-11-04 19:01 – Updated: 2022-11-08 19:00A vulnerability in the web-based management interface of Cisco Email Security Appliance (ESA), Cisco Secure Email and Web Manager, and Cisco Secure Web Appliance, formerly known as Cisco Web Security Appliance (WSA), could allow an authenticated, remote attacker to retrieve sensitive information from an affected device, including user credentials. This vulnerability is due to weak enforcement of back-end authorization checks. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to obtain confidential data that is stored on the affected device.
{
"affected": [],
"aliases": [
"CVE-2022-20942"
],
"database_specific": {
"cwe_ids": [
"CWE-359",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-04T18:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco Email Security Appliance (ESA), Cisco Secure Email and Web Manager, and Cisco Secure Web Appliance, formerly known as Cisco Web Security Appliance (WSA), could allow an authenticated, remote attacker to retrieve sensitive information from an affected device, including user credentials. This vulnerability is due to weak enforcement of back-end authorization checks. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to obtain confidential data that is stored on the affected device.",
"id": "GHSA-96p6-q6gp-f474",
"modified": "2022-11-08T19:00:24Z",
"published": "2022-11-04T19:01:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20942"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cnt-sec-infodiscl-BVKKnUG"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cnt-sec-infodiscl-BVKKnUG"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-973F-JFVH-694J
Vulnerability from github – Published: 2025-01-03 15:30 – Updated: 2025-01-03 15:30IBM Jazz Foundation 7.0.2, 7.0.3, and 7.1.0 could
could allow a physical user to obtain sensitive information due to not masking passwords during entry.
{
"affected": [],
"aliases": [
"CVE-2024-41780"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-03T15:15:10Z",
"severity": "MODERATE"
},
"details": "IBM Jazz Foundation 7.0.2, 7.0.3, and 7.1.0 could \n\ncould allow a physical user to obtain sensitive information due to not masking passwords during entry.",
"id": "GHSA-973f-jfvh-694j",
"modified": "2025-01-03T15:30:38Z",
"published": "2025-01-03T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41780"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7180119"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-97JG-43C9-Q6PF
Vulnerability from github – Published: 2022-04-08 21:53 – Updated: 2022-04-19 15:25A guest user without the right to view pages of the wiki can still list documents related to users of the wiki. The problem has been patched in XWiki versions 12.10.11, 13.4.4, and 13.9-rc-1. There is no known workaround for this problem.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-templates"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.10.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-templates"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "13.4.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-templates"
},
"ranges": [
{
"events": [
{
"introduced": "13.5.0"
},
{
"fixed": "13.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-24819"
],
"database_specific": {
"cwe_ids": [
"CWE-359"
],
"github_reviewed": true,
"github_reviewed_at": "2022-04-08T21:53:38Z",
"nvd_published_at": "2022-04-08T20:15:00Z",
"severity": "MODERATE"
},
"details": "A guest user without the right to view pages of the wiki can still list documents related to users of the wiki. The problem has been patched in XWiki versions 12.10.11, 13.4.4, and 13.9-rc-1. There is no known workaround for this problem.",
"id": "GHSA-97jg-43c9-q6pf",
"modified": "2022-04-19T15:25:47Z",
"published": "2022-04-08T21:53:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-97jg-43c9-q6pf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24819"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-18850"
}
],
"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"
}
],
"summary": "Unauthenticated user can retrieve the list of users through uorgsuggest.vm"
}
GHSA-98M6-R63J-Q88Q
Vulnerability from github – Published: 2024-11-14 09:30 – Updated: 2024-11-15 00:31Unauthorized access vulnerability in the mobile application (com.transsion.phoenix) can lead to the leakage of user information.
{
"affected": [],
"aliases": [
"CVE-2024-11206"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-359"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-14T07:15:17Z",
"severity": "HIGH"
},
"details": "Unauthorized access vulnerability in the mobile application (com.transsion.phoenix) can lead to the leakage of user information.",
"id": "GHSA-98m6-r63j-q88q",
"modified": "2024-11-15T00:31:50Z",
"published": "2024-11-14T09:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11206"
},
{
"type": "WEB",
"url": "https://security.tecno.com/SRC/blogdetail/340?lang=en_US"
},
{
"type": "WEB",
"url": "https://security.tecno.com/SRC/securityUpdates"
}
],
"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"
}
]
}
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.