Common Weakness Enumeration

CWE-204

Allowed

Observable Response Discrepancy

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.

359 vulnerabilities reference this CWE, most recent first.

GHSA-4FQ5-58J6-9QPH

Vulnerability from github – Published: 2023-07-10 18:30 – Updated: 2026-06-01 15:30
VLAI
Details

Observable Response Discrepancy in the SICK ICR890-4 could allow a remote attacker to identify valid usernames for the FTP server from the response given during a failed login attempt.

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-2023-35698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-10T16:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Observable Response Discrepancy in the SICK ICR890-4 could allow a remote attacker to identify valid usernames for the FTP server from the response given during a failed login\nattempt.",
  "id": "GHSA-4fq5-58j6-9qph",
  "modified": "2026-06-01T15:30:31Z",
  "published": "2023-07-10T18:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35698"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0006.json"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0006.pdf"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/psirt"
    }
  ],
  "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-4G8M-5MJ5-C8XG

Vulnerability from github – Published: 2025-05-06 16:38 – Updated: 2025-05-06 19:57
VLAI
Summary
Umbraco Makes User Enumeration Feasible Based on Timing of Login Response
Details

Impact

Based on an analysis of the timing of post login API responses, it's possible to determine whether an account exists.

Patches

Patched in 10.8.10 and 13.8.1.

Workarounds

None available.

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": "NuGet",
        "name": "Umbraco.Cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-rc1"
            },
            {
              "fixed": "13.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Umbraco.Cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.8.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-06T16:38:55Z",
    "nvd_published_at": "2025-05-06T17:16:12Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nBased on an analysis of the timing of post login API responses, it\u0027s possible to determine whether an account exists.\n\n### Patches\nPatched in 10.8.10 and 13.8.1.\n\n### Workarounds\nNone available.",
  "id": "GHSA-4g8m-5mj5-c8xg",
  "modified": "2025-05-06T19:57:06Z",
  "published": "2025-05-06T16:38:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umbraco/Umbraco-CMS/security/advisories/GHSA-4g8m-5mj5-c8xg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46736"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umbraco/Umbraco-CMS/commit/14fbd20665b453cbf094ccf4575b79a9fba07e03"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umbraco/Umbraco-CMS/commit/34709be6cce9752dfa767dffbf551305f48839bc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umbraco/Umbraco-CMS"
    }
  ],
  "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": "Umbraco Makes User Enumeration Feasible Based on Timing of Login Response"
}

GHSA-4GRF-X53V-R95X

Vulnerability from github – Published: 2024-05-03 18:30 – Updated: 2024-05-03 18:30
VLAI
Details

IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 could allow a remote user to enumerate usernames due to differentiating error messages on existing usernames. IBM X-Force ID: 199181.

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-2021-20556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T18:15:07Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 could allow a remote user to enumerate usernames due to differentiating error messages on existing usernames.  IBM X-Force ID:  199181.",
  "id": "GHSA-4grf-x53v-r95x",
  "modified": "2024-05-03T18:30:37Z",
  "published": "2024-05-03T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20556"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/199181"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7149876"
    }
  ],
  "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-4VPG-GWQQ-W44C

Vulnerability from github – Published: 2026-10-02 23:05 – Updated: 2026-10-02 23:05
VLAI
Summary
SiYuan: 17 block metadata/content endpoints in kernel/api/block.go have zero publish-access filtering, reachable by anonymous publish-mode readers
Details

Same CWE-862 family, found via an automated bulk sweep of every /api/block/* handler in kernel/api/block.go for the presence of any access-check reference (IsReadOnlyRoleContext, checkBlockPublishAccess, GetPublishAccess) anywhere in the function body. 17 of 28 candidate endpoints have none. Cross-checked against the file's own sibling functions (getBlockInfo, getBlockDOM, getRefIDs, etc.), which correctly implement the check, confirming this is a real, uneven gap rather than a deliberate design choice for the whole file.

Summary

17 handlers in kernel/api/block.go, all gated only by model.CheckAuth with no admin-role requirement, return block content-derived text, structural metadata, or existence information for any block ID supplied, with no access check anywhere in the handler or, for the ones checked in detail, the model functions they call. This is CWE-862 (Missing Authorization), the same class as the companion advisories from this review round, found in a different file via a systematic bulk check rather than manual inspection of each function individually.

Details

Confirmed via automated extraction of every function body between func NAME(c *gin.Context) { and the next such declaration, then searching each for any of IsReadOnlyRoleContext, checkBlockPublishAccess, GetPublishAccess, or PublishAccess. The following contain none of these, at all:

Endpoint What it discloses
getRefText The block's actual reference-display text, derived from its content, for any ID (kernel/api/block.go:564)
getBlockBreadcrumb The block's breadcrumb/title path (:?)
getBlockDefIDsByRefText Which block IDs a given reference text resolves to
getRefIDsByFileAnnotationID Block IDs referencing a given PDF/file annotation
getBlockIndex / getBlocksIndexes A block's position/index within its document
getTreeStat Structural statistics for a document tree
getBlocksWordCount / getContentWordCount Word/character counts for arbitrary content
checkBlockExist / checkBlocksExist Existence oracle for any block ID
getUnfoldedParentID The nearest unfolded ancestor of a block
checkBlockFold Whether a block is currently folded
getBlockSiblingID A block's sibling in document order
getBlockRelevantIDs IDs of blocks related to a given block
getBlockTreeInfos Block tree metadata for a set of IDs
checkBlockRef Whether a block is referenced elsewhere

The clearest, most severe example, getRefText (POST /api/block/getRefText, kernel/api/router.go:238):

func getRefText(c *gin.Context) {
    ...
    id := arg["id"].(string)
    if util.InvalidIDPattern(id, ret) {
        return
    }
    var refText string
    if notebook, ok := arg["notebook"].(string); ok && notebook != "" && model.IsEncryptedBox(notebook) {
        refText = model.GetBlockRefTextInBox(id, notebook)
    } else {
        refText = model.GetBlockRefText(id)
    }
    ...
    ret.Data = refText
}

model.GetBlockRefText(id) resolves the actual display text used wherever this block is referenced, ordinarily derived from the block's real content, for any id in the workspace, with no scoping.

For contrast, sibling functions in the same file correctly implement the check, e.g. getRefIDs (kernel/api/router.go:235) and getBlockInfo/getBlockDOM/getBlockKramdown all contain if model.IsReadOnlyRoleContext(c) { ... } guards. This confirms the 17 above are an inconsistency within the file, not an intentional decision that the whole file is exempt from this control.

Step-by-step reproduction

# id: a block inside a document that was never published, or is
# Disable=true in publish access
curl -s -X POST http://<target>:6806/api/block/getRefText \
  -H "Content-Type: application/json" -d '{"id":"<private-block-id>"}'
# Returns the block's actual reference text with no session, no
# AccessAuthCode, no publish password.

curl -s -X POST http://<target>:6806/api/block/checkBlockExist \
  -H "Content-Type: application/json" -d '{"id":"<guessed-block-id>"}'
# Confirms or denies existence of any guessed ID workspace-wide.

Repeat against any of the other 15 endpoints in the table above, substituting their expected arguments, each returns data with no access check.

Impact

Any published SiYuan workspace discloses block-level content-derived text, structural metadata, and existence information for the entire workspace, not just published notebooks, to any anonymous internet visitor. getRefText in particular discloses real content text, not just metadata, for any block ID. The existence-oracle endpoints (checkBlockExist/checkBlockRef) combine with the companion advisory's getIDsByHPath title-guessing primitive to let an attacker efficiently probe for and confirm private content without ever needing legitimate access. ```

Affected products

Field Value
Ecosystem Go
Package name github.com/siyuan-note/siyuan/kernel
Affected versions Present at current HEAD (commit eef1056/1673b75, reviewed 2026-08-03)
Patched versions (none yet, leave blank until a fix is released)

Severity

Field Value
Vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Score 7.5 (High). Network vector, low complexity, no privileges or user interaction required, high confidentiality impact via getRefText's real content-text disclosure plus the combined structural/existence oracle from the other 16, no integrity/availability impact since all 17 are read-only.

Weaknesses (CWE)

  • CWE-862: Missing Authorization (primary)
  • CWE-204: Observable Response Discrepancy (contributing, via the existence-oracle endpoints)

Notes for filing

  • Same CWE-862 family as the two companion advisories from this review round (asset/attribute-view listing, and path/title resolution). Recommend the maintainers treat all three as one remediation pass: grep every /api/* handler for the literal presence of IsReadOnlyRoleContext and manually audit every one that lacks it, rather than fixing endpoint-by-endpoint, since the pattern has now recurred across three separate files.
  • Suggested fix: add if model.IsReadOnlyRoleContext(c) { ... } guards matching the pattern already correctly used by this file's own getBlockInfo/getBlockDOM/getRefIDs functions.
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": "Go",
        "name": "github.com/siyuan-note/siyuan/kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260804015139-bd067a4fe9b2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-74904"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-02T23:05:33Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Same CWE-862 family, found via an automated bulk sweep of every\n`/api/block/*` handler in `kernel/api/block.go` for the presence of any\naccess-check reference (`IsReadOnlyRoleContext`, `checkBlockPublishAccess`,\n`GetPublishAccess`) anywhere in the function body. 17 of 28 candidate\nendpoints have none. Cross-checked against the file\u0027s own sibling\nfunctions (`getBlockInfo`, `getBlockDOM`, `getRefIDs`, etc.), which\ncorrectly implement the check, confirming this is a real, uneven gap\nrather than a deliberate design choice for the whole file.\n\n\n### Summary\n17 handlers in `kernel/api/block.go`, all gated only by `model.CheckAuth`\nwith no admin-role requirement, return block content-derived text,\nstructural metadata, or existence information for any block ID supplied,\nwith no access check anywhere in the handler or, for the ones checked in\ndetail, the model functions they call. This is CWE-862 (Missing\nAuthorization), the same class as the companion advisories from this\nreview round, found in a different file via a systematic bulk check\nrather than manual inspection of each function individually.\n\n### Details\nConfirmed via automated extraction of every function body between\n`func NAME(c *gin.Context) {` and the next such declaration, then\nsearching each for any of `IsReadOnlyRoleContext`,\n`checkBlockPublishAccess`, `GetPublishAccess`, or `PublishAccess`. The\nfollowing contain none of these, at all:\n\n| Endpoint | What it discloses |\n|---|---|\n| `getRefText` | The block\u0027s actual reference-display text, derived from its content, for any ID (`kernel/api/block.go:564`) |\n| `getBlockBreadcrumb` | The block\u0027s breadcrumb/title path (`:?`) |\n| `getBlockDefIDsByRefText` | Which block IDs a given reference text resolves to |\n| `getRefIDsByFileAnnotationID` | Block IDs referencing a given PDF/file annotation |\n| `getBlockIndex` / `getBlocksIndexes` | A block\u0027s position/index within its document |\n| `getTreeStat` | Structural statistics for a document tree |\n| `getBlocksWordCount` / `getContentWordCount` | Word/character counts for arbitrary content |\n| `checkBlockExist` / `checkBlocksExist` | Existence oracle for any block ID |\n| `getUnfoldedParentID` | The nearest unfolded ancestor of a block |\n| `checkBlockFold` | Whether a block is currently folded |\n| `getBlockSiblingID` | A block\u0027s sibling in document order |\n| `getBlockRelevantIDs` | IDs of blocks related to a given block |\n| `getBlockTreeInfos` | Block tree metadata for a set of IDs |\n| `checkBlockRef` | Whether a block is referenced elsewhere |\n\nThe clearest, most severe example, `getRefText`\n(`POST /api/block/getRefText`, `kernel/api/router.go:238`):\n```go\nfunc getRefText(c *gin.Context) {\n    ...\n    id := arg[\"id\"].(string)\n    if util.InvalidIDPattern(id, ret) {\n        return\n    }\n    var refText string\n    if notebook, ok := arg[\"notebook\"].(string); ok \u0026\u0026 notebook != \"\" \u0026\u0026 model.IsEncryptedBox(notebook) {\n        refText = model.GetBlockRefTextInBox(id, notebook)\n    } else {\n        refText = model.GetBlockRefText(id)\n    }\n    ...\n    ret.Data = refText\n}\n```\n`model.GetBlockRefText(id)` resolves the actual display text used\nwherever this block is referenced, ordinarily derived from the block\u0027s\nreal content, for any `id` in the workspace, with no scoping.\n\nFor contrast, sibling functions in the same file correctly implement\nthe check, e.g. `getRefIDs` (`kernel/api/router.go:235`) and\n`getBlockInfo`/`getBlockDOM`/`getBlockKramdown` all contain\n`if model.IsReadOnlyRoleContext(c) { ... }` guards. This confirms the\n17 above are an inconsistency within the file, not an intentional\ndecision that the whole file is exempt from this control.\n\n### Step-by-step reproduction\n```bash\n# id: a block inside a document that was never published, or is\n# Disable=true in publish access\ncurl -s -X POST http://\u003ctarget\u003e:6806/api/block/getRefText \\\n  -H \"Content-Type: application/json\" -d \u0027{\"id\":\"\u003cprivate-block-id\u003e\"}\u0027\n# Returns the block\u0027s actual reference text with no session, no\n# AccessAuthCode, no publish password.\n\ncurl -s -X POST http://\u003ctarget\u003e:6806/api/block/checkBlockExist \\\n  -H \"Content-Type: application/json\" -d \u0027{\"id\":\"\u003cguessed-block-id\u003e\"}\u0027\n# Confirms or denies existence of any guessed ID workspace-wide.\n```\nRepeat against any of the other 15 endpoints in the table above,\nsubstituting their expected arguments, each returns data with no\naccess check.\n\n### Impact\nAny published SiYuan workspace discloses block-level content-derived\ntext, structural metadata, and existence information for the *entire*\nworkspace, not just published notebooks, to any anonymous internet\nvisitor. `getRefText` in particular discloses real content text, not\njust metadata, for any block ID. The existence-oracle endpoints\n(`checkBlockExist`/`checkBlockRef`) combine with the companion\nadvisory\u0027s `getIDsByHPath` title-guessing primitive to let an attacker\nefficiently probe for and confirm private content without ever needing\nlegitimate access.\n```\n\n## Affected products\n\n| Field | Value |\n|---|---|\n| Ecosystem | **Go** |\n| Package name | `github.com/siyuan-note/siyuan/kernel` |\n| Affected versions | Present at current HEAD (commit `eef1056`/`1673b75`, reviewed 2026-08-03) |\n| Patched versions | *(none yet, leave blank until a fix is released)* |\n\n## Severity\n\n| Field | Value |\n|---|---|\n| Vector string | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` |\n| Score | **7.5 (High)**. Network vector, low complexity, no privileges or user interaction required, high confidentiality impact via `getRefText`\u0027s real content-text disclosure plus the combined structural/existence oracle from the other 16, no integrity/availability impact since all 17 are read-only. |\n\n## Weaknesses (CWE)\n\n- **CWE-862**: Missing Authorization (primary)\n- **CWE-204**: Observable Response Discrepancy (contributing, via the existence-oracle endpoints)\n\n## Notes for filing\n- Same CWE-862 family as the two companion advisories from this review\n  round (asset/attribute-view listing, and path/title resolution).\n  Recommend the maintainers treat all three as one remediation pass:\n  grep every `/api/*` handler for the literal presence of\n  `IsReadOnlyRoleContext` and manually audit every one that lacks it,\n  rather than fixing endpoint-by-endpoint, since the pattern has now\n  recurred across three separate files.\n- Suggested fix: add `if model.IsReadOnlyRoleContext(c) { ... }` guards\n  matching the pattern already correctly used by this file\u0027s own\n  `getBlockInfo`/`getBlockDOM`/`getRefIDs` functions.",
  "id": "GHSA-4vpg-gwqq-w44c",
  "modified": "2026-10-02T23:05:33Z",
  "published": "2026-10-02T23:05:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-4vpg-gwqq-w44c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74904"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/commit/bd067a4fe9b208c0858d8d9dc6220dc8affc403e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siyuan-note/siyuan"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/releases/tag/v3.8.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/siyuan-before-missing-authorization-via-block-api"
    }
  ],
  "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": "SiYuan: 17 block metadata/content endpoints in kernel/api/block.go have zero publish-access filtering, reachable by anonymous publish-mode readers"
}

GHSA-552F-97WF-PMPQ

Vulnerability from github – Published: 2024-03-20 17:54 – Updated: 2025-02-12 18:19
VLAI
Summary
Umbraco possible user enumeration
Details

Impact

A user enumeration attack is possible.

Affected versions

Umbraco 10 with access to the native login screen

Patches

This is fixed in 10.8.5

Workarounds

Disabling the native login screen, by exclusively use external logins.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "UmbracoCMS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-28868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-20T17:54:35Z",
    "nvd_published_at": "2024-03-20T20:15:09Z",
    "severity": "LOW"
  },
  "details": "### Impact\nA user enumeration attack is possible.\n\n### Affected versions\nUmbraco 10 with access to the native login screen\n\n### Patches\nThis is fixed in 10.8.5\n\n\n### Workarounds\nDisabling the native login screen, by exclusively use external logins.",
  "id": "GHSA-552f-97wf-pmpq",
  "modified": "2025-02-12T18:19:44Z",
  "published": "2024-03-20T17:54:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umbraco/Umbraco-CMS/security/advisories/GHSA-552f-97wf-pmpq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28868"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umbraco/Umbraco-CMS/commit/7e1d1a1968000226cd882fff078b122b8d46c44d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umbraco/Umbraco-CMS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Umbraco possible user enumeration "
}

GHSA-56J3-W2R5-QGXQ

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30
VLAI
Details

userSpice 4.3.24 contains a username enumeration vulnerability that allows unauthenticated attackers to discover valid usernames by sending POST requests to the existingUsernameCheck.php endpoint. Attackers can submit usernames and analyze response text for the 'taken' string to identify existing accounts in the system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-25350"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-23T19:16:55Z",
    "severity": "CRITICAL"
  },
  "details": "userSpice 4.3.24 contains a username enumeration vulnerability that allows unauthenticated attackers to discover valid usernames by sending POST requests to the existingUsernameCheck.php endpoint. Attackers can submit usernames and analyze response text for the \u0027taken\u0027 string to identify existing accounts in the system.",
  "id": "GHSA-56j3-w2r5-qgxq",
  "modified": "2026-05-26T13:30:27Z",
  "published": "2026-05-26T13:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25350"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/44872"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/userspice-username-enumeration-via-existingusernamecheck-php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/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-56J8-MPH9-634W

Vulnerability from github – Published: 2026-07-17 15:32 – Updated: 2026-07-17 15:32
VLAI
Details

HCL Aftermarket EPC is vulnerable to attack since It was found that a malicious actor can use brute-force techniques to either guess or confirm valid users in the system. Use renumeration is when a malicious actor can use brute-force techniques to either guess or confirm valid users in a system

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-2024-23574"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T14:17:17Z",
    "severity": "MODERATE"
  },
  "details": "HCL Aftermarket EPC is vulnerable to attack since It was found that a malicious actor can use brute-force techniques to either guess or confirm valid users in the system. Use renumeration is when a malicious actor can use brute-force techniques to either guess or confirm valid users in a system",
  "id": "GHSA-56j8-mph9-634w",
  "modified": "2026-07-17T15:32:30Z",
  "published": "2026-07-17T15:32:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23574"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0132294"
    }
  ],
  "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-579X-CJVR-CQJ9

Vulnerability from github – Published: 2021-09-20 19:53 – Updated: 2021-09-17 18:38
VLAI
Summary
Observable Response Discrepancy in Lost Password Service
Details

Impact

It is possible to enumerate usernames via the forgot password functionality

Patches

Update to version 10.1.3 or apply this patch manually: https://github.com/pimcore/pimcore/pull/10223.patch

Workarounds

Apply https://github.com/pimcore/pimcore/pull/10223.patch manually.

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": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-39189"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-17T18:38:47Z",
    "nvd_published_at": "2021-09-15T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nIt is possible to enumerate usernames via the forgot password functionality\n\n### Patches\nUpdate to version `10.1.3` or apply this patch manually: https://github.com/pimcore/pimcore/pull/10223.patch\n\n### Workarounds\nApply https://github.com/pimcore/pimcore/pull/10223.patch manually. \n",
  "id": "GHSA-579x-cjvr-cqj9",
  "modified": "2021-09-17T18:38:47Z",
  "published": "2021-09-20T19:53:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/security/advisories/GHSA-579x-cjvr-cqj9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39189"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/pull/10223.patch"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/pull/10223/commits/d0a4de39cf05dce6af71f8ca039132bdfcbb0dce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pimcore/pimcore"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/12462a99-ebf8-4e39-80b3-54a16caa3f4c"
    }
  ],
  "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": "Observable Response Discrepancy in Lost Password Service"
}

GHSA-59MP-P3M2-6WR7

Vulnerability from github – Published: 2026-07-01 15:35 – Updated: 2026-07-06 15:30
VLAI
Details

MCO is vulnerable to User Enumeration through authentication-related functionalities. The application returns distinguishable responses for valid and invalid users during username reminder and password reset operations. An attacker can leverage these differences to enumerate valid usernames and email addresses.

Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-53908"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T13:17:45Z",
    "severity": "MODERATE"
  },
  "details": "MCO is vulnerable to User Enumeration through authentication-related functionalities. The application returns distinguishable responses for valid and invalid users during username reminder and password reset operations. An attacker can leverage these differences to enumerate valid usernames and email addresses.\n\nBecause vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1\u00a0but may also affect other versions.",
  "id": "GHSA-59mp-p3m2-6wr7",
  "modified": "2026-07-06T15:30:45Z",
  "published": "2026-07-01T15:35:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53908"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2026/07/CVE-2026-53902"
    },
    {
      "type": "WEB",
      "url": "https://mco.mycomplianceoffice.com"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/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-5F5C-8RVC-J8WF

Vulnerability from github – Published: 2024-07-15 17:49 – Updated: 2024-07-15 21:39
VLAI
Summary
OpaMiddleware does not filter HTTP OPTIONS requests
Details

Summary

HTTP OPTIONS requests are always allowed by OpaMiddleware, even when they lack authentication, and are passed through directly to the application.

The maintainer uncertain whether this should be classed as a "bug" or "security issue" – but is erring on the side of "security issue" as an application could reasonably assume OPA controls apply to all HTTP methods, and it bypasses more sophisticated policies.

Details

OpaMiddleware allows all HTTP OPTIONS requests without evaluating it against any policy:

https://github.com/busykoala/fastapi-opa/blob/6dd6f8c87e908fe080784a74707f016f1422b58a/fastapi_opa/opa/opa_middleware.py#L79-L80

If an application provides different responses to HTTP OPTIONS requests based on an entity existing (such as to indicate whether an entity is writable on a system level), an unauthenticated attacker could discover which entities exist within an application (CWE-204).

PoC

This toy application is based on the behaviour of an app[^1] which can use fastapi-opa. The app uses the Allow header of a HTTP OPTIONS to indicate whether an entity is writable on a "system" level, and returns HTTP 404 for unknown entities:

[^1]: an open source app, not written by me

# Run with: fastapi dev opa-poc.py --port 9999
from fastapi import FastAPI, Response, HTTPException
from fastapi_opa import OPAConfig, OPAMiddleware
from fastapi_opa.auth.auth_api_key import APIKeyAuthentication, APIKeyConfig

# OPA doesn't actually need to be running for this example
opa_host = "http://localhost:8181"
api_key_config = APIKeyConfig(
    header_key = 'ApiKey',
    api_key = 'secret-key',
)
api_key_auth = APIKeyAuthentication(api_key_config)
opa_config = OPAConfig(authentication=api_key_auth, opa_host=opa_host)

app = FastAPI()
app.add_middleware(OPAMiddleware, config=opa_config)

WRITABLE_ITEMS = {
    1: True,
    2: False,
}


@app.get("/")
async def root() -> dict:
    return {"msg": "success"}

@app.get("/items/{item_id}")
async def read_item(item_id: int):
    if item_id not in WRITABLE_ITEMS:
        raise HTTPException(status_code=404)
    return {"item_id": item_id}

@app.options("/items/{item_id}")
async def read_item_options(response: Response, item_id: int) -> dict:
    if item_id not in WRITABLE_ITEMS:
        raise HTTPException(status_code=404)

    response.headers["Allow"] = "OPTIONS, GET" + (", POST" if WRITABLE_ITEMS[item_id] else "")
    return {}

As expected, HTTP GET requests fail consistently when unauthenticated, regardless of whether the entity exists, because read_item() is never executed:

$ curl -i 'http://localhost:9999/items/1'
HTTP/1.1 401 Unauthorized
server: uvicorn
content-length: 26
content-type: application/json

{"message":"Unauthorized"}

$ curl -i 'http://localhost:9999/items/3'
HTTP/1.1 401 Unauthorized
server: uvicorn
content-length: 26
content-type: application/json

{"message":"Unauthorized"}

However, HTTP OPTIONS requests are never authenticated by OpaMiddleware, so are passed straight through to read_item_options() and returned to unauthenticated users:

$ curl -i -X OPTIONS 'http://localhost:9999/items/1'
HTTP/1.1 200 OK
server: uvicorn
content-length: 2
content-type: application/json
allow: OPTIONS, GET, POST

{}

$ curl -i -X OPTIONS 'http://localhost:9999/items/2'
HTTP/1.1 200 OK
server: uvicorn
content-length: 2
content-type: application/json
allow: OPTIONS, GET

{}

$ curl -i -X OPTIONS 'http://localhost:9999/items/3'
HTTP/1.1 404 Not Found
server: uvicorn
content-length: 22
content-type: application/json

{"detail":"Not Found"}

Versions

fastapi-opa==2.0.0
fastapi==0.111.0
Severity
5.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fastapi-opa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-40627"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-15T17:49:25Z",
    "nvd_published_at": "2024-07-15T20:15:05Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nHTTP `OPTIONS` requests are always allowed by `OpaMiddleware`, even when they lack authentication, and are passed through directly to the application.\n\nThe maintainer uncertain whether this should be classed as a \"bug\" or \"security issue\" \u2013 but is erring on the side of \"security issue\" as an application could reasonably assume OPA controls apply to *all* HTTP methods, and it bypasses more sophisticated policies.\n\n### Details\n\n`OpaMiddleware` allows all HTTP `OPTIONS` requests without evaluating it against any policy:\n\nhttps://github.com/busykoala/fastapi-opa/blob/6dd6f8c87e908fe080784a74707f016f1422b58a/fastapi_opa/opa/opa_middleware.py#L79-L80\n\nIf an application provides different responses to HTTP `OPTIONS` requests based on an entity existing (such as to indicate whether an entity is writable on a system level), an unauthenticated attacker could discover which entities exist within an application (CWE-204).\n\n### PoC\n\nThis toy application is based on the behaviour of an app[^1] which can use `fastapi-opa`. The app uses the `Allow` header of a HTTP `OPTIONS` to indicate whether an entity is writable on a \"system\" level, and returns HTTP 404 for unknown entities:\n\n[^1]: an open source app, not written by me\n\n```python\n# Run with: fastapi dev opa-poc.py --port 9999\nfrom fastapi import FastAPI, Response, HTTPException\nfrom fastapi_opa import OPAConfig, OPAMiddleware\nfrom fastapi_opa.auth.auth_api_key import APIKeyAuthentication, APIKeyConfig\n\n# OPA doesn\u0027t actually need to be running for this example\nopa_host = \"http://localhost:8181\"\napi_key_config = APIKeyConfig(\n    header_key = \u0027ApiKey\u0027,\n    api_key = \u0027secret-key\u0027,\n)\napi_key_auth = APIKeyAuthentication(api_key_config)\nopa_config = OPAConfig(authentication=api_key_auth, opa_host=opa_host)\n\napp = FastAPI()\napp.add_middleware(OPAMiddleware, config=opa_config)\n\nWRITABLE_ITEMS = {\n    1: True,\n    2: False,\n}\n\n\n@app.get(\"/\")\nasync def root() -\u003e dict:\n    return {\"msg\": \"success\"}\n\n@app.get(\"/items/{item_id}\")\nasync def read_item(item_id: int):\n    if item_id not in WRITABLE_ITEMS:\n        raise HTTPException(status_code=404)\n    return {\"item_id\": item_id}\n\n@app.options(\"/items/{item_id}\")\nasync def read_item_options(response: Response, item_id: int) -\u003e dict:\n    if item_id not in WRITABLE_ITEMS:\n        raise HTTPException(status_code=404)\n\n    response.headers[\"Allow\"] = \"OPTIONS, GET\" + (\", POST\" if WRITABLE_ITEMS[item_id] else \"\")\n    return {}\n```\n\nAs expected, HTTP `GET` requests fail consistently when unauthenticated, regardless of whether the entity exists, because `read_item()` is never executed:\n\n```\n$ curl -i \u0027http://localhost:9999/items/1\u0027\nHTTP/1.1 401 Unauthorized\nserver: uvicorn\ncontent-length: 26\ncontent-type: application/json\n\n{\"message\":\"Unauthorized\"}\n\n$ curl -i \u0027http://localhost:9999/items/3\u0027\nHTTP/1.1 401 Unauthorized\nserver: uvicorn\ncontent-length: 26\ncontent-type: application/json\n\n{\"message\":\"Unauthorized\"}\n```\n\nHowever, HTTP `OPTIONS` requests are never authenticated by `OpaMiddleware`, so are passed straight through to `read_item_options()` and returned to unauthenticated users:\n\n```\n$ curl -i -X OPTIONS \u0027http://localhost:9999/items/1\u0027\nHTTP/1.1 200 OK\nserver: uvicorn\ncontent-length: 2\ncontent-type: application/json\nallow: OPTIONS, GET, POST\n\n{}\n\n$ curl -i -X OPTIONS \u0027http://localhost:9999/items/2\u0027\nHTTP/1.1 200 OK\nserver: uvicorn\ncontent-length: 2\ncontent-type: application/json\nallow: OPTIONS, GET\n\n{}\n\n$ curl -i -X OPTIONS \u0027http://localhost:9999/items/3\u0027\nHTTP/1.1 404 Not Found\nserver: uvicorn\ncontent-length: 22\ncontent-type: application/json\n\n{\"detail\":\"Not Found\"}\n```\n\n### Versions\n\n```\nfastapi-opa==2.0.0\nfastapi==0.111.0\n```",
  "id": "GHSA-5f5c-8rvc-j8wf",
  "modified": "2024-07-15T21:39:12Z",
  "published": "2024-07-15T17:49:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/busykoala/fastapi-opa/security/advisories/GHSA-5f5c-8rvc-j8wf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40627"
    },
    {
      "type": "WEB",
      "url": "https://github.com/busykoala/fastapi-opa/commit/9458845a6f6f414c0b79587fae83d7f14d74dfb4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/busykoala/fastapi-opa/commit/9588109ff651f7ffc92687129c4956126443fb8c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/busykoala/fastapi-opa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/busykoala/fastapi-opa/blob/6dd6f8c87e908fe080784a74707f016f1422b58a/fastapi_opa/opa/opa_middleware.py#L79-L80"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpaMiddleware does not filter HTTP OPTIONS requests"
}
Mitigation MIT-46
Architecture and Design

Strategy: Separation of Privilege

  • Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Mitigation MIT-39
Implementation
  • Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
  • If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
  • Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
CAPEC-331: ICMP IP Total Length Field Probe

An adversary sends a UDP packet to a closed port on the target machine to solicit an IP Header's total length field value within the echoed 'Port Unreachable" error message. This type of behavior is useful for building a signature-base of operating system responses, particularly when error messages contain other types of information that is useful identifying specific operating system responses.

CAPEC-332: ICMP IP 'ID' Field Error Message Probe

An adversary sends a UDP datagram having an assigned value to its internet identification field (ID) to a closed port on a target to observe the manner in which this bit is echoed back in the ICMP error message. This allows the attacker to construct a fingerprint of specific OS behaviors.

CAPEC-541: Application Fingerprinting

An adversary engages in fingerprinting activities to determine the type or version of an application installed on a remote target.

CAPEC-580: System Footprinting

An adversary engages in active probing and exploration activities to determine security information about a remote target system. Often times adversaries will rely on remote applications that can be probed for system configurations.

← Back to the CWE list