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.

323 vulnerabilities reference this CWE, most recent first.

GHSA-RH28-MQJ4-8X59

Vulnerability from github – Published: 2026-05-26 20:16 – Updated: 2026-05-26 20:17
VLAI
Summary
XWiki Platform's Livetable results still allow reconstructing password hashes using 768 requests
Details

Impact

XWiki discovered that the patch for GHSA-5cf8-vrr8-8hjm was insufficient and with slightly modified parameters to the LiveTableResults, it is still possible to discover password hashes one bit at a time, so with 768 requests, the full password salt and hash can be retrieved of a user.

Patches

The check for password (and email properties) has been adjusted in XWiki 18.0.0RC1, 17.10.13, 17.4.9 and 16.10.17.

Workarounds

The patch can be applied manually to the wiki page XWiki.LiveTableResultsMacros.

Resources

  • https://jira.xwiki.org/browse/XWIKI-23875
  • https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa
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": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-livetable-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.2.1"
            },
            {
              "fixed": "16.10.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-livetable-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "17.0.0-rc-1"
            },
            {
              "fixed": "17.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-livetable-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "17.5.0-rc-1"
            },
            {
              "fixed": "17.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-26T20:16:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nXWiki discovered that the patch for GHSA-5cf8-vrr8-8hjm was insufficient and with slightly modified parameters to the `LiveTableResults`, it is still possible to discover password hashes one bit at a time, so with 768 requests, the full password salt and hash can be retrieved of a user.\n\n### Patches\nThe check for password (and email properties) has been adjusted in XWiki 18.0.0RC1, 17.10.13, 17.4.9 and 16.10.17.\n\n### Workarounds\nThe [patch](https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa#diff-5a739e5865b1f1ad9d79b724791be51b0095a0170cc078911c940478b13b949a) can be applied manually to the wiki page `XWiki.LiveTableResultsMacros`.\n\n### Resources\n* https://jira.xwiki.org/browse/XWIKI-23875\n* https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa",
  "id": "GHSA-rh28-mqj4-8x59",
  "modified": "2026-05-26T20:17:00Z",
  "published": "2026-05-26T20:16:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-rh28-mqj4-8x59"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-23875"
    }
  ],
  "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\u0027s Livetable results still allow reconstructing password hashes using 768 requests"
}

GHSA-RJ4G-RQGH-RX9H

Vulnerability from github – Published: 2026-05-07 21:16 – Updated: 2026-05-07 21:16
VLAI
Summary
Ech0 comment model's Email field returned on public /api/comments endpoints
Details

Summary

The Comment model serializes its Email field through the public comment-listing API. internal/model/comment/comment.go:33 uses json:"email", while adjacent PII fields (IPHash, UserAgent) correctly use json:"-". The public endpoints GET /api/comments?echo_id=X and GET /api/comments/public?limit=N both live on PublicRouterGroup with no authentication. Alice retrieves every guest commenter's email address on the instance with a few unauthenticated HTTP calls.

Details

The Comment model at internal/model/comment/comment.go:33:

type Comment struct {
    // ... 
    Email     string     `gorm:"size:255;not null;index" json:"email"`
    IPHash    string     `gorm:"size:128;index"          json:"-"`
    UserAgent string     `gorm:"size:512"                json:"-"`
    // ...
}

The json:"-" on IPHash and UserAgent shows the developer's intent: hide server-side PII from API responses. The Email field missed the same tag. GORM materializes the full struct and the Gin handler returns it verbatim.

Routes at internal/router/comment.go:20 and comment public-feed route:

appRouterGroup.PublicRouterGroup.GET("/comments", middleware.NoCache(), h.CommentHandler.ListCommentsByEchoID())
appRouterGroup.PublicRouterGroup.GET("/comments/public", middleware.NoCache(), h.CommentHandler.ListPublicComments())

Both handlers call ListPublicByEchoID (service at internal/service/comment/comment.go:329) or ListPublicComments (service at :340), both of which return the slice of Comment structs to ctx.JSON. No DTO projection, no field stripping.

The email field is populated for every guest comment: the submission form requires an email address so the server can later send moderation or reply notifications. The UI does not display the email, so users assume it stays server-side.

GHSA-m983-7426-5hrj (2026-03-22) closed a similar PII leak on GET /api/allusers, which exposed account-owner emails. This report covers a distinct endpoint (/api/comments and /api/comments/public) and a distinct data subject (guest commenters, not registered account owners).

Proof of Concept

Anonymous caller harvests commenter emails on the default install:

import requests
TARGET = "http://localhost:8300"

# Any echo UUID from the public feed.
pub_id = requests.get(f"{TARGET}/api/echo/page?page=1&pageSize=1").json()["data"]["items"][0]["id"]

# No auth header. The response includes the raw email field.
r = requests.get(f"{TARGET}/api/comments", params={"echo_id": pub_id})
for c in r.json()["data"]:
    print(f"  nickname={c['nickname']!r}  email={c.get('email')!r}")

# The /public variant returns recent comments across every echo.
r = requests.get(f"{TARGET}/api/comments/public", params={"limit": 100})
emails = {c.get("email") for c in r.json()["data"] if c.get("email")}
print(f"harvested {len(emails)} unique emails from /comments/public")

Observed on v4.5.6:

nickname='GuestHarvestMe'  email='leaked-harvest-target@example.com'
harvested 1 unique emails from /comments/public

The instance had one guest comment; its email returned in both endpoints. An instance with any commenter volume returns every address.

Impact

Anonymous harvest of every guest commenter's email address across the instance. Email addresses submitted for moderation or reply notifications are treated as private by user expectation; any visitor pulls the full list with a short paginated loop against /api/comments/public. Privacy-regulation exposure follows:

  • GDPR and CCPA. Email is personal data. Exposing it to any internet visitor without consent is a notifiable incident under both regimes.
  • Spam and phishing targeting. Attackers map commenter emails to nicknames and per-echo topics, then send targeted phishing that references content the victim engaged with.
  • Cross-instance aggregation. A scraper against any public-facing Ech0 instance yields a curated list of people who comment on the topics the site covers.

No authentication required. No admin role required. The /comments/public endpoint returns cross-echo aggregated data, so one call covers the whole instance.

Recommended Fix

Change the JSON tag on the Email field to match the adjacent PII fields:

Email string `gorm:"size:255;not null;index" json:"-"`

Or, if some authenticated view needs the email, introduce a PublicComment DTO that projects only non-sensitive fields:

type PublicComment struct {
    ID        string    `json:"id"`
    EchoID    string    `json:"echo_id"`
    Nickname  string    `json:"nickname"`
    Website   string    `json:"website,omitempty"`
    Content   string    `json:"content"`
    Status    string    `json:"status"`
    Hot       bool      `json:"hot"`
    Source    string    `json:"source"`
    CreatedAt int64     `json:"created_at"`
    UpdatedAt int64     `json:"updated_at"`
}

Project the handler output through this DTO. Keep the raw Comment struct internal to the service layer.

Found by aisafe.io

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lin-snow/Ech0"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.8-0.20260503034700-cb8d7a997dd8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-359"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T21:16:15Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `Comment` model serializes its `Email` field through the public comment-listing API. `internal/model/comment/comment.go:33` uses `json:\"email\"`, while adjacent PII fields (`IPHash`, `UserAgent`) correctly use `json:\"-\"`. The public endpoints `GET /api/comments?echo_id=X` and `GET /api/comments/public?limit=N` both live on `PublicRouterGroup` with no authentication. Alice retrieves every guest commenter\u0027s email address on the instance with a few unauthenticated HTTP calls.\n\n## Details\n\nThe Comment model at `internal/model/comment/comment.go:33`:\n\n```go\ntype Comment struct {\n    // ... \n    Email     string     `gorm:\"size:255;not null;index\" json:\"email\"`\n    IPHash    string     `gorm:\"size:128;index\"          json:\"-\"`\n    UserAgent string     `gorm:\"size:512\"                json:\"-\"`\n    // ...\n}\n```\n\nThe `json:\"-\"` on `IPHash` and `UserAgent` shows the developer\u0027s intent: hide server-side PII from API responses. The `Email` field missed the same tag. GORM materializes the full struct and the Gin handler returns it verbatim.\n\nRoutes at `internal/router/comment.go:20` and comment public-feed route:\n\n```go\nappRouterGroup.PublicRouterGroup.GET(\"/comments\", middleware.NoCache(), h.CommentHandler.ListCommentsByEchoID())\nappRouterGroup.PublicRouterGroup.GET(\"/comments/public\", middleware.NoCache(), h.CommentHandler.ListPublicComments())\n```\n\nBoth handlers call `ListPublicByEchoID` (service at `internal/service/comment/comment.go:329`) or `ListPublicComments` (service at `:340`), both of which return the slice of `Comment` structs to `ctx.JSON`. No DTO projection, no field stripping.\n\nThe email field is populated for every guest comment: the submission form requires an email address so the server can later send moderation or reply notifications. The UI does not display the email, so users assume it stays server-side.\n\nGHSA-m983-7426-5hrj (2026-03-22) closed a similar PII leak on `GET /api/allusers`, which exposed account-owner emails. This report covers a distinct endpoint (`/api/comments` and `/api/comments/public`) and a distinct data subject (guest commenters, not registered account owners).\n\n## Proof of Concept\n\nAnonymous caller harvests commenter emails on the default install:\n\n```python\nimport requests\nTARGET = \"http://localhost:8300\"\n\n# Any echo UUID from the public feed.\npub_id = requests.get(f\"{TARGET}/api/echo/page?page=1\u0026pageSize=1\").json()[\"data\"][\"items\"][0][\"id\"]\n\n# No auth header. The response includes the raw email field.\nr = requests.get(f\"{TARGET}/api/comments\", params={\"echo_id\": pub_id})\nfor c in r.json()[\"data\"]:\n    print(f\"  nickname={c[\u0027nickname\u0027]!r}  email={c.get(\u0027email\u0027)!r}\")\n\n# The /public variant returns recent comments across every echo.\nr = requests.get(f\"{TARGET}/api/comments/public\", params={\"limit\": 100})\nemails = {c.get(\"email\") for c in r.json()[\"data\"] if c.get(\"email\")}\nprint(f\"harvested {len(emails)} unique emails from /comments/public\")\n```\n\nObserved on v4.5.6:\n\n```\nnickname=\u0027GuestHarvestMe\u0027  email=\u0027leaked-harvest-target@example.com\u0027\nharvested 1 unique emails from /comments/public\n```\n\nThe instance had one guest comment; its email returned in both endpoints. An instance with any commenter volume returns every address.\n\n## Impact\n\nAnonymous harvest of every guest commenter\u0027s email address across the instance. Email addresses submitted for moderation or reply notifications are treated as private by user expectation; any visitor pulls the full list with a short paginated loop against `/api/comments/public`. Privacy-regulation exposure follows:\n\n- **GDPR and CCPA.** Email is personal data. Exposing it to any internet visitor without consent is a notifiable incident under both regimes.\n- **Spam and phishing targeting.** Attackers map commenter emails to nicknames and per-echo topics, then send targeted phishing that references content the victim engaged with.\n- **Cross-instance aggregation.** A scraper against any public-facing Ech0 instance yields a curated list of people who comment on the topics the site covers.\n\nNo authentication required. No admin role required. The `/comments/public` endpoint returns cross-echo aggregated data, so one call covers the whole instance.\n\n## Recommended Fix\n\nChange the JSON tag on the Email field to match the adjacent PII fields:\n\n```go\nEmail string `gorm:\"size:255;not null;index\" json:\"-\"`\n```\n\nOr, if some authenticated view needs the email, introduce a `PublicComment` DTO that projects only non-sensitive fields:\n\n```go\ntype PublicComment struct {\n    ID        string    `json:\"id\"`\n    EchoID    string    `json:\"echo_id\"`\n    Nickname  string    `json:\"nickname\"`\n    Website   string    `json:\"website,omitempty\"`\n    Content   string    `json:\"content\"`\n    Status    string    `json:\"status\"`\n    Hot       bool      `json:\"hot\"`\n    Source    string    `json:\"source\"`\n    CreatedAt int64     `json:\"created_at\"`\n    UpdatedAt int64     `json:\"updated_at\"`\n}\n```\n\nProject the handler output through this DTO. Keep the raw `Comment` struct internal to the service layer.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
  "id": "GHSA-rj4g-rqgh-rx9h",
  "modified": "2026-05-07T21:16:15Z",
  "published": "2026-05-07T21:16:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lin-snow/Ech0/security/advisories/GHSA-rj4g-rqgh-rx9h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lin-snow/Ech0/commit/cb8d7a997dd8f573ef0e22e4e6b23b2b8ee92ebd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lin-snow/Ech0"
    }
  ],
  "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": "Ech0 comment model\u0027s Email field returned on public /api/comments endpoints"
}

GHSA-RJRQ-626C-Q262

Vulnerability from github – Published: 2025-02-14 00:30 – Updated: 2025-02-14 00:30
VLAI
Details

The Qardio Arm iOS application exposes sensitive data such as usernames and passwords in a plist file. This allows an attacker to log in to production-level development accounts and access an engineering backdoor in the application. The engineering backdoor allows the attacker to send hex-based commands over a UI-based terminal.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-20615"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-13T22:15:11Z",
    "severity": "MODERATE"
  },
  "details": "The Qardio Arm iOS application exposes sensitive data such as usernames \nand passwords in a plist file. This allows an attacker to log in to \nproduction-level development accounts and access an engineering backdoor\n in the application. The engineering backdoor allows the attacker to \nsend hex-based commands over a UI-based terminal.",
  "id": "GHSA-rjrq-626c-q262",
  "modified": "2025-02-14T00:30:44Z",
  "published": "2025-02-14T00:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20615"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-medical-advisories/icsma-25-044-01"
    },
    {
      "type": "WEB",
      "url": "https://www.qardio.com/about-us/#contact"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RR7J-V2Q5-CHGV

Vulnerability from github – Published: 2026-04-16 01:20 – Updated: 2026-04-24 20:52
VLAI
Summary
LangSmith SDK: Streaming token events bypass output redaction
Details

Summary

The LangSmith SDK's output redaction controls (hideOutputs in JS, hide_outputs in Python) do not apply to streaming token events. When an LLM run produces streaming output, each chunk is recorded as a new_token event containing the raw token value. These events bypass the redaction pipeline entirely — prepareRunCreateOrUpdateInputs (JS) and _hide_run_outputs (Python) only process the inputs and outputs fields on a run, never the events array. As a result, applications relying on output redaction to prevent sensitive LLM output from being stored in LangSmith will still leak the full streamed content via run events.

Details

Both JS and Python SDKs are affected. The same pattern exists in both:

  • JS SDK: traceable.ts:997-1003 and traceable.ts:1044-1050
  • Python SDK: run_helpers.py:1924 and run_helpers.py:1996

In both SDKs, new_token events with raw kwargs.token values are added during streaming, and the redaction pipeline (hideOutputs in JS, hide_outputs in Python) only processes inputs/outputs — never events.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.18"
      },
      "package": {
        "ecosystem": "npm",
        "name": "langsmith"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.7.30"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "langsmith"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-359",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T01:20:37Z",
    "nvd_published_at": "2026-04-23T02:16:16Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe LangSmith SDK\u0027s output redaction controls (hideOutputs in JS, hide_outputs in Python) do not apply to streaming token events. When an LLM run produces streaming output, each chunk is recorded as a new_token event containing the raw token value. These events bypass the redaction pipeline entirely \u2014 prepareRunCreateOrUpdateInputs (JS) and _hide_run_outputs (Python) only process the inputs and outputs fields on a run, never the events array. As a result, applications relying on output redaction to prevent sensitive LLM output from being stored in LangSmith will still leak the full streamed content via run events.\n\n## Details\n\n**Both JS and Python SDKs are affected.** The same pattern exists in both:\n\n- **JS SDK**: `traceable.ts:997-1003` and `traceable.ts:1044-1050`\n- **Python SDK**: `run_helpers.py:1924` and `run_helpers.py:1996`\n\nIn both SDKs, `new_token` events with raw `kwargs.token` values are added during streaming, and the redaction pipeline (`hideOutputs` in JS, `hide_outputs` in Python) only processes `inputs`/`outputs` \u2014 never `events`.",
  "id": "GHSA-rr7j-v2q5-chgv",
  "modified": "2026-04-24T20:52:13Z",
  "published": "2026-04-16T01:20:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langsmith-sdk/security/advisories/GHSA-rr7j-v2q5-chgv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41182"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langchain-ai/langsmith-sdk"
    }
  ],
  "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": "LangSmith SDK: Streaming token events bypass output redaction"
}

GHSA-V2J2-FRQ6-6V5G

Vulnerability from github – Published: 2026-01-14 15:32 – Updated: 2026-01-14 15:32
VLAI
Details

In Crazy Bubble Tea mobile application authenticated attacker can obtain personal information about other users by enumerating a loyaltyGuestId parameter. Server does not verify the permissions required to obtain the data.

This issue was fixed in version 915 (Android) and 7.4.1 (iOS).

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-14317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-14T14:16:11Z",
    "severity": "HIGH"
  },
  "details": "In Crazy Bubble Tea mobile application authenticated attacker can\u00a0obtain personal information about other users by enumerating a `loyaltyGuestId` parameter. Server\u00a0does not verify the permissions required to obtain the data.\n\n\nThis issue was fixed in version\u00a0915 (Android) and 7.4.1 (iOS).",
  "id": "GHSA-v2j2-frq6-6v5g",
  "modified": "2026-01-14T15:32:59Z",
  "published": "2026-01-14T15:32:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14317"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/posts/2026/01/CVE-2025-14317"
    },
    {
      "type": "WEB",
      "url": "https://crazybubble.pl/aplikacja-crazy-bubble"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/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-V34R-VJ4R-38J6

Vulnerability from github – Published: 2025-01-24 18:45 – Updated: 2025-01-24 18:45
VLAI
Summary
Updatecli exposes Maven credentials in console output
Details

Summary

Private maven repository credentials leaked in application logs in case of unsuccessful retrieval operation.

Details

During the execution of an updatecli pipeline which contains a maven source configured with basic auth credentials, the credentials are being leaked in the application execution logs in case of failure.

Credentials are properly sanitized when the operation is successful but not when for whatever reason there is a failure in the maven repository .e.g. wrong coordinates provided, not existing artifact or version.

PoC

The documentation currently state to provide user credentials as basic auth inside the repository field. e.g.

sources:
  default:
    kind: maven
    spec:
      repository: "{{ requiredEnv "MAVEN_USERNAME" }}:{{ requiredEnv "MAVEN_PASS" }}@repo.example.org/releases"
      groupid: "org.example.company"
      artifactid: "my-artifact"
      versionFilter:
        kind: regex
        pattern: "^23(\.[0-9]+){1,2}$"

Logs are sanitized properly in case of a successful operation:

source: source#default
-----------------------------------------------------------
Searching for version matching pattern "^23(\\.[0-9]+){1,2}$"
✔ Latest version is 23.4.0 on the Maven repository at https://repo.example.org/releases/org/example/company/my-artifact/maven-metadata.xml

but leaks credentials in case the GAV coordinates are wrong (misspelled package name or missing):

source: source#default
-----------------------------------------------------------
ERROR: ✗ getting latest version: URL "https://REDACTED:REDACTED@repo.example.org/releases/org/example/company/wrong-artifact/maven-metadata.xml" not found or in error

Impact

User credentials/token used to authenticate against a private maven repository can be leaked in clear-text in console or CI logs.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/updatecli/updatecli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.93.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24355"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-24T18:45:20Z",
    "nvd_published_at": "2025-01-24T17:15:16Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPrivate maven repository credentials leaked in application logs in case of unsuccessful retrieval operation.\n\n### Details\n\nDuring the execution of an updatecli pipeline which contains a `maven` source configured with basic auth credentials, the credentials are being leaked in the application execution logs in case of failure.\n\nCredentials are properly sanitized when the operation is successful but not when for whatever reason there is a failure in the maven repository .e.g. wrong coordinates provided, not existing artifact or version.\n\n### PoC\n\nThe [documentation](https://www.updatecli.io/docs/plugins/resource/maven/) currently state to provide user credentials as basic auth inside the `repository` field. e.g.\n\n```\nsources:\n  default:\n    kind: maven\n    spec:\n      repository: \"{{ requiredEnv \"MAVEN_USERNAME\" }}:{{ requiredEnv \"MAVEN_PASS\" }}@repo.example.org/releases\"\n      groupid: \"org.example.company\"\n      artifactid: \"my-artifact\"\n      versionFilter:\n        kind: regex\n        pattern: \"^23(\\.[0-9]+){1,2}$\"\n```\n\nLogs are sanitized properly in case of a successful operation:\n\n```\nsource: source#default\n-----------------------------------------------------------\nSearching for version matching pattern \"^23(\\\\.[0-9]+){1,2}$\"\n\u2714 Latest version is 23.4.0 on the Maven repository at https://repo.example.org/releases/org/example/company/my-artifact/maven-metadata.xml\n```\n\nbut leaks credentials in case the GAV coordinates are wrong (misspelled package name or missing):\n\n```\nsource: source#default\n-----------------------------------------------------------\nERROR: \u2717 getting latest version: URL \"https://REDACTED:REDACTED@repo.example.org/releases/org/example/company/wrong-artifact/maven-metadata.xml\" not found or in error\n```\n\n### Impact\n\nUser credentials/token used to authenticate against a private maven repository can be leaked in clear-text in console or CI logs.",
  "id": "GHSA-v34r-vj4r-38j6",
  "modified": "2025-01-24T18:45:21Z",
  "published": "2025-01-24T18:45:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/updatecli/updatecli/security/advisories/GHSA-v34r-vj4r-38j6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24355"
    },
    {
      "type": "WEB",
      "url": "https://github.com/updatecli/updatecli/commit/344b28091ffeca5ed32e8d0f9eda542842fcd3fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/updatecli/updatecli"
    },
    {
      "type": "WEB",
      "url": "https://www.updatecli.io/docs/plugins/resource/maven"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Updatecli exposes Maven credentials in console output"
}

GHSA-V3W5-WFJX-FH47

Vulnerability from github – Published: 2024-09-10 03:31 – Updated: 2024-09-10 03:31
VLAI
Details

Due to missing authorization checks, SAP Business Warehouse (BEx Analyzer) allows an authenticated attacker to access information over the network which is otherwise restricted. On successful exploitation the attacker can enumerate information causing a limited impact on confidentiality of the application.

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": [],
  "aliases": [
    "CVE-2024-44113"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T03:15:02Z",
    "severity": "MODERATE"
  },
  "details": "Due to missing authorization checks, SAP Business Warehouse (BEx Analyzer) allows an authenticated attacker to access information over the network which is otherwise restricted. On successful exploitation the attacker can enumerate information causing a limited impact on confidentiality of the application.",
  "id": "GHSA-v3w5-wfjx-fh47",
  "modified": "2024-09-10T03:31:32Z",
  "published": "2024-09-10T03:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44113"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3481992"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "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"
    }
  ]
}

GHSA-V5VH-6MHH-H6GC

Vulnerability from github – Published: 2026-04-21 15:32 – Updated: 2026-04-22 00:31
VLAI
Details

Information disclosure in the Form Autofill component. This vulnerability was fixed in Firefox 150 and Firefox ESR 140.10.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6765"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T13:16:22Z",
    "severity": "MODERATE"
  },
  "details": "Information disclosure in the Form Autofill component. This vulnerability was fixed in Firefox 150 and Firefox ESR 140.10.",
  "id": "GHSA-v5vh-6mhh-h6gc",
  "modified": "2026-04-22T00:31:38Z",
  "published": "2026-04-21T15:32:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6765"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2022419"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-30"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-32"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-33"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-34"
    }
  ],
  "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"
    }
  ]
}

GHSA-VFC9-FGWM-8MWP

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-58296"
  ],
  "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-vfc9-fgwm-8mwp",
  "modified": "2026-07-03T21:31:40Z",
  "published": "2026-07-03T21:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58296"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-58296"
    }
  ],
  "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-VGGF-H36F-57FP

Vulnerability from github – Published: 2024-09-11 12:30 – Updated: 2024-09-18 18:30
VLAI
Details

This vulnerability exists in Reedos aiM-Star version 2.0.1 due to transmission of sensitive information in plain text in certain API endpoints. An authenticated remote attacker could exploit this vulnerability by manipulating a parameter through API request URL and intercepting response of the API request leading to exposure of sensitive information belonging to other users.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-45787"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-11T12:15:02Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability exists in Reedos aiM-Star version 2.0.1 due to transmission of sensitive information in plain text in certain API endpoints. An authenticated remote attacker could exploit this vulnerability by manipulating a parameter through API request URL and intercepting response of the API request leading to exposure of sensitive information belonging to other users.",
  "id": "GHSA-vggf-h36f-57fp",
  "modified": "2024-09-18T18:30:50Z",
  "published": "2024-09-11T12:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45787"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2024-0291"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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"
    }
  ]
}
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