Common Weakness Enumeration

CWE-204

Allowed

Observable Response Discrepancy

Abstraction: Base · Status: Incomplete

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.

303 vulnerabilities reference this CWE, most recent first.

GHSA-Q32W-QVCR-5JR4

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

SAP HANA Database (user self service tools) allows an unauthenticated user to send specially crafted requests that produce distinguishable responses, enabling enumeration of valid user accounts and email addresses. Successful exploitation could allow the attacker to enumerate valid user accounts, resulting in low impact on confidentiality, with no impact on integrity and availability of the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44753"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T01:16:17Z",
    "severity": "LOW"
  },
  "details": "SAP HANA Database (user self service tools) allows an unauthenticated user to send specially crafted requests that produce distinguishable responses, enabling enumeration of valid user accounts and email addresses. Successful exploitation could allow the attacker to enumerate valid user accounts, resulting in low impact on confidentiality, with no impact on integrity and availability of the application.",
  "id": "GHSA-q32w-qvcr-5jr4",
  "modified": "2026-07-14T03:31:36Z",
  "published": "2026-07-14T03:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44753"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3732522"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "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"
    }
  ]
}

GHSA-Q3QX-CP62-F6M7

Vulnerability from github – Published: 2025-12-02 00:38 – Updated: 2025-12-02 00:38
VLAI
Summary
Grav Admin Plugin vulnerable to User Enumeration & Email Disclosure
Details

Grav v1.7.49.5 / Admin v1.10.49.1 – User Enumeration & Email Disclosure

Summary

A user enumeration and email disclosure vulnerability exists in Grav v1.7.49.5 with Admin plugin v1.10.49.1.
The "Forgot Password" functionality at /admin/forgot leaks information about valid usernames and their associated email addresses through distinct server responses.
This allows an attacker to enumerate users and disclose sensitive email addresses, which can be leveraged for targeted attacks such as password spraying, phishing, or social engineering.

Details

The issue resides in the taskForgot() function, which handles the forgot password workflow.
Relevant vulnerable logic:

if (null === $user || $user->state !== 'enabled' || !$to) {
    ...
    // Generic message for invalid/non-existing users
    $this->setMessage($this->translate('PLUGIN_ADMIN.FORGOT_INSTRUCTIONS_SENT_VIA_EMAIL'));
    return $this->createRedirectResponse($current);
}

if ($rateLimiter->isRateLimited($username)) {
    ...
    $interval = $config->get('plugins.login.max_pw_resets_interval', 2);

    // Sensitive message for valid users
    $this->setMessage($this->translate('PLUGIN_LOGIN.FORGOT_CANNOT_RESET_IT_IS_BLOCKED', $to, $interval), 'error');

    return $this->createRedirectResponse($current);
}

When an attacker submits the password reset form at /admin/forgot with an invalid username, the application responds with:

Instructions to reset your password have been sent to your email address

However, when a valid username is supplied, and the attacker repeatedly triggers password reset requests, the application responds with:

Cannot reset password for <USER_EMAIL>, password reset functionality temporarily blocked, please try later (maximum 60 minutes)

This discrepancy in responses enables:
1. User Enumeration – Attackers can determine if a username exists in the system by analyzing the response.
2. User Email Disclosure – The system discloses the actual email address associated with the account (e.g., admin@localhost.test).

This violates best practices for authentication flows, where responses should remain generic to avoid leaking sensitive information.

PoC

  1. Navigate to the Forgot Password page: https://<target>/admin/forgot
  2. Submit a reset request with a random/invalid username (e.g., invalid_user):

  3. Response:
    Instructions to reset your password have been sent to your email address

  4. Submit a reset request with a valid username (e.g., admin).
  5. Repeatedly request a reset for the same username until the lockout mechanism triggers.
  6. Response:
    Cannot reset password for admin@localhost.test, password reset functionality temporarily blocked, please try later (maximum 60 minutes)
  7. Observe the leaked email address of the admin account in the error message.

Impact

  • Severity: Medium
  • Type: Information Disclosure / User Enumeration
  • Who is Impacted: All Grav sites using Admin plugin v1.10.49.1 with password reset enabled.
  • Risks:
  • Allows attackers to enumerate valid usernames.
  • Exposes email addresses of admin accounts, which can be used in:
  • Credential stuffing
  • Password spraying
  • Phishing/social engineering campaigns
  • Further exploitation in combination with other vulnerabilities

Recommendation

  • Modify the taskForgot() logic to always return a generic, non-identifying message, regardless of whether the username exists or rate limits are hit.

  • Example safe response: ini If the account exists, password reset instructions will be sent.

  • Do not include email addresses ($to) or other sensitive data in error messages.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.0-beta.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66307"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-02T00:38:24Z",
    "nvd_published_at": "2025-12-01T22:15:50Z",
    "severity": "MODERATE"
  },
  "details": "# Grav v1.7.49.5 / Admin v1.10.49.1 \u2013 User Enumeration \u0026 Email Disclosure\n\n### Summary\nA **user enumeration and email disclosure vulnerability** exists in Grav **v1.7.49.5** with Admin plugin **v1.10.49.1**.  \nThe \"Forgot Password\" functionality at `/admin/forgot` leaks information about valid usernames and their associated email addresses through distinct server responses.  \nThis allows an attacker to enumerate users and disclose sensitive email addresses, which can be leveraged for targeted attacks such as password spraying, phishing, or social engineering.  \n\n### Details\n\nThe issue resides in the [`taskForgot()`](https://github.com/getgrav/grav-plugin-admin/blob/6d673fc7c4f6962756f93ae651371e81f7f20924/classes/plugin/Controllers/Login/LoginController.php#L349) function, which handles the forgot password workflow.  \nRelevant vulnerable logic:\n\n```php\nif (null === $user || $user-\u003estate !== \u0027enabled\u0027 || !$to) {\n    ...\n    // Generic message for invalid/non-existing users\n    $this-\u003esetMessage($this-\u003etranslate(\u0027PLUGIN_ADMIN.FORGOT_INSTRUCTIONS_SENT_VIA_EMAIL\u0027));\n    return $this-\u003ecreateRedirectResponse($current);\n}\n\nif ($rateLimiter-\u003eisRateLimited($username)) {\n    ...\n    $interval = $config-\u003eget(\u0027plugins.login.max_pw_resets_interval\u0027, 2);\n\n    // Sensitive message for valid users\n    $this-\u003esetMessage($this-\u003etranslate(\u0027PLUGIN_LOGIN.FORGOT_CANNOT_RESET_IT_IS_BLOCKED\u0027, $to, $interval), \u0027error\u0027);\n\n    return $this-\u003ecreateRedirectResponse($current);\n}\n```\n\nWhen an attacker submits the password reset form at `/admin/forgot` with an **invalid username**, the application responds with:  \n\n```\nInstructions to reset your password have been sent to your email address\n```\n\nHowever, when a **valid username** is supplied, and the attacker repeatedly triggers password reset requests, the application responds with:  \n\n```\nCannot reset password for \u003cUSER_EMAIL\u003e, password reset functionality temporarily blocked, please try later (maximum 60 minutes)\n```\n\nThis discrepancy in responses enables:  \n1. **User Enumeration** \u2013 Attackers can determine if a username exists in the system by analyzing the response.  \n2. **User Email Disclosure** \u2013 The system discloses the actual email address associated with the account (e.g., `admin@localhost.test`).  \n\nThis violates best practices for authentication flows, where responses should remain generic to avoid leaking sensitive information.\n\n### PoC\n1. Navigate to the **Forgot Password** page:  `https://\u003ctarget\u003e/admin/forgot`\n1. Submit a reset request with a random/invalid username (e.g., `invalid_user`):  \n\n- Response:  \n  ```\n  Instructions to reset your password have been sent to your email address\n  ```\n3. Submit a reset request with a valid username (e.g., `admin`).  \n4. Repeatedly request a reset for the same username until the lockout mechanism triggers.  \n- Response:  \n  ```\n  Cannot reset password for admin@localhost.test, password reset functionality temporarily blocked, please try later (maximum 60 minutes)\n  ```\n5. Observe the leaked **email address** of the admin account in the error message.  \n\n### Impact\n- **Severity:** Medium  \n- **Type:** Information Disclosure / User Enumeration  \n- **Who is Impacted:** All Grav sites using Admin plugin **v1.10.49.1** with password reset enabled.  \n- **Risks:**  \n  - Allows attackers to enumerate valid usernames.  \n  - Exposes email addresses of admin accounts, which can be used in:  \n  - Credential stuffing  \n  - Password spraying  \n  - Phishing/social engineering campaigns  \n  - Further exploitation in combination with other vulnerabilities  \n\n\n### Recommendation\n\n- Modify the [`taskForgot()`](https://github.com/getgrav/grav-plugin-admin/blob/6d673fc7c4f6962756f93ae651371e81f7f20924/classes/plugin/Controllers/Login/LoginController.php#L349) logic to always return a generic, non-identifying message, regardless of whether the username exists or rate limits are hit.\n\n- Example safe response:\n  ```ini\n  If the account exists, password reset instructions will be sent.\n  ```\n\n- Do not include email addresses ($to) or other sensitive data in error messages.",
  "id": "GHSA-q3qx-cp62-f6m7",
  "modified": "2025-12-02T00:38:24Z",
  "published": "2025-12-02T00:38:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-q3qx-cp62-f6m7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66307"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav-plugin-admin/commit/99f653296504f1d6408510dd2f6f20a45a26f9b0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav-plugin-admin/blob/6d673fc7c4f6962756f93ae651371e81f7f20924/classes/plugin/Controllers/Login/LoginController.php#L349"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Grav Admin Plugin vulnerable to User Enumeration \u0026 Email Disclosure"
}

GHSA-Q4MQ-W4V3-MV77

Vulnerability from github – Published: 2024-03-07 21:30 – Updated: 2024-03-07 21:30
VLAI
Details

IBM DS8900F HMC 89.21.19.0, 89.21.31.0, 89.30.68.0, 89.32.40.0, and 89.33.48.0 could allow an authenticated user to arbitrarily read files after enumerating file names. IBM X-Force ID: 269407.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-46170"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-07T21:15:06Z",
    "severity": "MODERATE"
  },
  "details": "\nIBM DS8900F HMC 89.21.19.0, 89.21.31.0, 89.30.68.0, 89.32.40.0, and 89.33.48.0 could allow an authenticated user to arbitrarily read files after enumerating file names. IBM X-Force ID: 269407.\n\n",
  "id": "GHSA-q4mq-w4v3-mv77",
  "modified": "2024-03-07T21:30:21Z",
  "published": "2024-03-07T21:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46170"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/269407"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7130084"
    }
  ],
  "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-Q5P6-RX6M-VX4M

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

IBM CICS TX Advanced 10.1 could disclose sensitive information to a remote attacker due to observable discrepancy in HTTP responses. IBM X-Force ID: 260814.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-38362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-04T16:15:49Z",
    "severity": "MODERATE"
  },
  "details": "IBM CICS TX Advanced 10.1 could disclose sensitive information to a remote attacker due to observable discrepancy in HTTP responses.  IBM X-Force ID:  260814.",
  "id": "GHSA-q5p6-rx6m-vx4m",
  "modified": "2024-03-04T18:30:35Z",
  "published": "2024-03-04T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38362"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/260814"
    },
    {
      "type": "WEB",
      "url": "https://https://www.ibm.com/support/pages/node/7066430"
    }
  ],
  "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-Q9FM-H69X-8J48

Vulnerability from github – Published: 2025-01-27 18:32 – Updated: 2025-01-27 18:32
VLAI
Details

IBM Sterling File Gateway 6.0.0.0 through 6.1.2.5 and 6.2.0.0 through 6.2.0.1 could allow an authenticated user to enumerate usernames due to an observable discrepancy in request responses.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-47159"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T16:15:29Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling File Gateway 6.0.0.0 through 6.1.2.5 and 6.2.0.0 through 6.2.0.1 could allow an authenticated user to enumerate usernames due to an observable discrepancy in request responses.",
  "id": "GHSA-q9fm-h69x-8j48",
  "modified": "2025-01-27T18:32:00Z",
  "published": "2025-01-27T18:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47159"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7176083"
    }
  ],
  "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-Q9X4-Q76F-5H5J

Vulnerability from github – Published: 2022-02-11 23:17 – Updated: 2023-01-10 15:48
VLAI
Summary
Unauthenticated users can exploit an enumeration vulnerability in Harbor (CVE-2019-19030)
Details

Impact

Sean Wright from Secureworks has discovered an enumeration vulnerability. An attacker can make use of the Harbor API to make unauthenticated calls to the Harbor instance. Based on the HTTP status code in the response, an attacker is then able to work out which resources exist, and which do not. This would likely be accomplished by either providing a wordlist or enumerating through a sequence an unauthenticated attacker is able to enumerate resources on the system. This provides them with information such as existing projects, repositories, etc.

The vulnerability was immediately fixed by the Harbor team.

Issue

The following API resources where found to be vulnerable to enumeration attacks: /api/chartrepo/{repo}/prov (POST) /api/chartrepo/{repo}/charts (GET, POST) /api/chartrepo/{repo}/charts/{name} (GET, DELETE) /api/chartrepo/{repo}/charts/{name}/{version} (GET, DELETE) /api/labels?name={name}&scope=p (GET) /api/repositories?project_id={id} (GET) /api/repositories/{repo_name}/ (GET, PUT, DELETE) /api/repositories/{repo_name}/tags (GET) /api/repositories/{repo_name}/tags/{tag}/manifest?version={version} (GET) /api/repositories/{repo_name/{tag}/labels (GET) /api/projects?project_name={name} (HEAD) /api/projects/{project_id}/summary (GET) /api/projects/{project_id}/logs (GET) /api/projects/{project_id} (GET, PUT, DELETE) /api/projects/{project_id}/metadatas (GET, POST) /api/projects/{project_id}/metadatas/{metadata_name} (GET, PUT)

Known Attack Vectors

Successful exploitation of this issue will lead to bad actors identifying which resources exist in Harbor without requiring authentication for the Harbor API.

Patches

If your product uses the affected releases of Harbor, update to version 1.10.3 or 2.0.1 to patch this issue immediately.

https://github.com/goharbor/harbor/releases/tag/v1.10.3 https://github.com/goharbor/harbor/releases/tag/v2.0.1

Workarounds

There is no known workaround

For more information

If you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io View our security policy at https://github.com/goharbor/harbor/security/policy

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-19030"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-24T18:52:37Z",
    "nvd_published_at": "2022-12-26T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "# Impact\nSean Wright from Secureworks has discovered an enumeration vulnerability. An attacker can make use of the Harbor API to make unauthenticated calls to the Harbor instance. Based on the HTTP status code in the response, an attacker is then able to work out which resources exist, and which do not. This would likely be accomplished by either providing a wordlist or enumerating through a sequence an\nunauthenticated attacker is able to enumerate resources on the system. This provides them with information such as existing projects, repositories, etc.\n\nThe vulnerability was immediately fixed by the Harbor team.  \n\n# Issue \nThe following API resources where found to be vulnerable to enumeration attacks:\n/api/chartrepo/{repo}/prov (POST)\n/api/chartrepo/{repo}/charts (GET, POST)\n/api/chartrepo/{repo}/charts/{name} (GET, DELETE)\n/api/chartrepo/{repo}/charts/{name}/{version} (GET, DELETE)\n/api/labels?name={name}\u0026scope=p (GET)\n/api/repositories?project_id={id} (GET)\n/api/repositories/{repo_name}/ (GET, PUT, DELETE)\n/api/repositories/{repo_name}/tags (GET)\n/api/repositories/{repo_name}/tags/{tag}/manifest?version={version} (GET)\n/api/repositories/{repo_name/{tag}/labels (GET)\n/api/projects?project_name={name} (HEAD)\n/api/projects/{project_id}/summary (GET)\n/api/projects/{project_id}/logs (GET)\n/api/projects/{project_id} (GET, PUT, DELETE)\n/api/projects/{project_id}/metadatas (GET, POST)\n/api/projects/{project_id}/metadatas/{metadata_name} (GET, PUT)\n\n# Known Attack Vectors\nSuccessful exploitation of this issue will lead to bad actors identifying which resources exist in Harbor without requiring authentication for the Harbor API.\n\n# Patches\nIf your product uses the affected releases of Harbor, update to version 1.10.3 or 2.0.1 to patch this issue immediately.\n\nhttps://github.com/goharbor/harbor/releases/tag/v1.10.3\nhttps://github.com/goharbor/harbor/releases/tag/v2.0.1\n\n# Workarounds\nThere is no known workaround\n\n# For more information\nIf you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io\nView our security policy at https://github.com/goharbor/harbor/security/policy",
  "id": "GHSA-q9x4-q76f-5h5j",
  "modified": "2023-01-10T15:48:41Z",
  "published": "2022-02-11T23:17:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/security/advisories/GHSA-q9x4-q76f-5h5j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19030"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor"
    }
  ],
  "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 users can exploit an enumeration vulnerability in Harbor (CVE-2019-19030)"
}

GHSA-QHP6-635J-X7R2

Vulnerability from github – Published: 2026-02-20 18:25 – Updated: 2026-02-23 22:28
VLAI
Summary
Static Web Server affected by timing-based username enumeration in Basic Authentication due to early response on invalid usernames
Details

Summary

A Timing-based username enumeration in Basic Authentication vulnerability due to early response on invalid usernames could allow attackers to identify valid users and focus their efforts on targeted brute-force or credential-stuffing attacks.

Details

SWS validates the provided username before performing any password verification. - Invalid Username: The server returns a 401 Unauthorized response immediately. - Valid Username: The server proceeds to verify the password (e.g., using bcrypt), which introduces a different execution path and measurable timing discrepancy.

This allows an attacker to distinguish between existing and non-existing accounts by analyzing response times.

PoC

The following statistical results were obtained by measuring the mean response time over 100 iterations using a custom Rust script:

User Type Average Response Time
Invalid User 0.409861 ms
Valid User 0.250925 ms
Difference ~0.158936 ms

While the valid user responded faster in this specific test environment, the statistically significant gap confirms that the authentication logic does not execute in constant time.

Impact

Users using the SWS' Basic Authentication feature are primarily impacted.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "static-web-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.41.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27480"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-20T18:25:27Z",
    "nvd_published_at": "2026-02-21T10:16:12Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA Timing-based username enumeration in Basic Authentication vulnerability due to early response on invalid usernames could allow attackers to identify valid users and focus their efforts on targeted brute-force or credential-stuffing attacks.\n\n## Details\n\nSWS validates the provided username before performing any password verification.\n- **Invalid Username:** The server returns a `401 Unauthorized` response immediately.\n- **Valid Username:** The server proceeds to verify the password (e.g., using `bcrypt`), which introduces a different execution path and measurable timing discrepancy.\n\nThis allows an attacker to distinguish between existing and non-existing accounts by analyzing response times.\n\n## PoC\n\nThe following statistical results were obtained by measuring the mean response time over 100 iterations using a custom Rust script:\n\n| User Type | Average Response Time |\n| :--- | :--- |\n| **Invalid User** | 0.409861 ms |\n| **Valid User** | 0.250925 ms |\n| **Difference** | **~0.158936 ms** |\n\nWhile the valid user responded faster in this specific test environment, the statistically significant gap confirms that the authentication logic does not execute in constant time.\n\n## Impact\n\nUsers using the SWS\u0027 Basic Authentication feature are primarily impacted.",
  "id": "GHSA-qhp6-635j-x7r2",
  "modified": "2026-02-23T22:28:57Z",
  "published": "2026-02-20T18:25:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/static-web-server/static-web-server/security/advisories/GHSA-qhp6-635j-x7r2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/static-web-server/static-web-server/commit/7bf0fd425eb10dac9bf9ef5febce12c4dd039ce1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/static-web-server/static-web-server"
    }
  ],
  "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": "Static Web Server affected by timing-based username enumeration in Basic Authentication due to early response on invalid usernames"
}

GHSA-QXRW-F6FH-34R7

Vulnerability from github – Published: 2026-05-06 23:49 – Updated: 2026-05-06 23:49
VLAI
Summary
Lemmy resend-verification endpoint exposes registered email addresses to unauthenticated users
Details

Summary

The unauthenticated resend-verification endpoint returns different responses for registered and unregistered email addresses. A malicious third party can submit candidate addresses to /api/v4/account/auth/resend_verification_email and distinguish accounts from misses.

Details

resend_verification_email() looks up the submitted address and returns the lookup error to the caller:

let local_user_view = LocalUserView::find_by_email(&mut context.pool(), &email).await?;
check_local_user_valid(&local_user_view)?;

The password reset endpoint already uses a safer pattern. It discards lookup errors and returns success, which prevents the same account-discovery channel.

Proof of Concept

The following script creates one user and probes that address plus a missing address.

import requests, random, string

BASE = "http://127.0.0.1:8536/api/v4"  # change to the target Lemmy URL
ADMIN_USER = "lemmy"
ADMIN_PASS = "lemmylemmy"
PASSWORD = "Password123456!"

def post(path, **body):
    return requests.post(BASE + path, json=body)

suffix = "enum" + "".join(random.choice(string.ascii_lowercase) for _ in range(6))
admin = post("/account/auth/login", username_or_email=ADMIN_USER, password=ADMIN_PASS).json()["jwt"]
requests.put(BASE + "/site", headers={"Authorization": "Bearer " + admin},
             json={"registration_mode": "open", "email_verification_required": False})

email = "alice" + suffix + "@example.test"
post("/account/auth/register", username="alice" + suffix, password=PASSWORD,
     password_verify=PASSWORD, email=email).raise_for_status()

for candidate in [email, "missing" + suffix + "@example.test"]:
    r = post("/account/auth/resend_verification_email", email=candidate)
    print(candidate, "HTTP", r.status_code, r.text[:300])

Output:

alicepoceudtpf@example.test HTTP 200 {"success":true}
missingpoceudtpf@example.test HTTP 404 {"error":"not_found","cause":"Record not found"}

Impact

A malicious third party can enumerate registered email addresses without authentication. The endpoint uses the registration rate limit bucket, not an endpoint-specific anti-enumeration limit, so the attacker can automate probes across candidate address lists. The response also distinguishes missing accounts from banned or deleted accounts because check_local_user_valid() returns separate error types.

Recommended Fix

Use the password-reset pattern for resend verification. Move the lookup and email-send work into a helper, ignore helper errors in the handler, and always return {"success": true} for syntactically valid input.


Found by aisafe.io

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "lemmy_api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.19.1-rc.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T23:49:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe unauthenticated resend-verification endpoint returns different responses for registered and unregistered email addresses. A malicious third party can submit candidate addresses to `/api/v4/account/auth/resend_verification_email` and distinguish accounts from misses.\n\n## Details\n\n`resend_verification_email()` looks up the submitted address and returns the lookup error to the caller:\n\n```rust\nlet local_user_view = LocalUserView::find_by_email(\u0026mut context.pool(), \u0026email).await?;\ncheck_local_user_valid(\u0026local_user_view)?;\n```\n\nThe password reset endpoint already uses a safer pattern. It discards lookup errors and returns success, which prevents the same account-discovery channel.\n\n## Proof of Concept\n\nThe following script creates one user and probes that address plus a missing address.\n\n```python\nimport requests, random, string\n\nBASE = \"http://127.0.0.1:8536/api/v4\"  # change to the target Lemmy URL\nADMIN_USER = \"lemmy\"\nADMIN_PASS = \"lemmylemmy\"\nPASSWORD = \"Password123456!\"\n\ndef post(path, **body):\n    return requests.post(BASE + path, json=body)\n\nsuffix = \"enum\" + \"\".join(random.choice(string.ascii_lowercase) for _ in range(6))\nadmin = post(\"/account/auth/login\", username_or_email=ADMIN_USER, password=ADMIN_PASS).json()[\"jwt\"]\nrequests.put(BASE + \"/site\", headers={\"Authorization\": \"Bearer \" + admin},\n             json={\"registration_mode\": \"open\", \"email_verification_required\": False})\n\nemail = \"alice\" + suffix + \"@example.test\"\npost(\"/account/auth/register\", username=\"alice\" + suffix, password=PASSWORD,\n     password_verify=PASSWORD, email=email).raise_for_status()\n\nfor candidate in [email, \"missing\" + suffix + \"@example.test\"]:\n    r = post(\"/account/auth/resend_verification_email\", email=candidate)\n    print(candidate, \"HTTP\", r.status_code, r.text[:300])\n\n```\n\nOutput:\n\n```text\nalicepoceudtpf@example.test HTTP 200 {\"success\":true}\nmissingpoceudtpf@example.test HTTP 404 {\"error\":\"not_found\",\"cause\":\"Record not found\"}\n```\n\n## Impact\n\nA malicious third party can enumerate registered email addresses without authentication. The endpoint uses the registration rate limit bucket, not an endpoint-specific anti-enumeration limit, so the attacker can automate probes across candidate address lists. The response also distinguishes missing accounts from banned or deleted accounts because `check_local_user_valid()` returns separate error types.\n\n## Recommended Fix\n\nUse the password-reset pattern for resend verification. Move the lookup and email-send work into a helper, ignore helper errors in the handler, and always return `{\"success\": true}` for syntactically valid input.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
  "id": "GHSA-qxrw-f6fh-34r7",
  "modified": "2026-05-06T23:49:18Z",
  "published": "2026-05-06T23:49:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/security/advisories/GHSA-qxrw-f6fh-34r7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/commit/4afff1699d08920b9a9023e81b229d772b894d91"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/LemmyNet/lemmy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Lemmy resend-verification endpoint exposes registered email addresses to unauthenticated users"
}

GHSA-R6J6-XP6Q-C876

Vulnerability from github – Published: 2022-02-22 00:00 – Updated: 2025-04-25 18:31
VLAI
Details

A vulnerability in Qlik Sense Enterprise on Windows could allow an remote attacker to enumerate domain user accounts. An attacker could exploit this vulnerability by sending authenticated requests to an affected system. A successful exploit could allow the attacker to compare the response time that are returned by the affected system to determine which accounts are valid user accounts. Affected systems are only vulnerable if they have LDAP configured.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-0564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-21T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in Qlik Sense Enterprise on Windows could allow an remote attacker to enumerate domain user accounts. An attacker could exploit this vulnerability by sending authenticated requests to an affected system. A successful exploit could allow the attacker to compare the response time that are returned by the affected system to determine which accounts are valid user accounts. Affected systems are only vulnerable if they have LDAP configured.",
  "id": "GHSA-r6j6-xp6q-c876",
  "modified": "2025-04-25T18:31:01Z",
  "published": "2022-02-22T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0564"
    },
    {
      "type": "WEB",
      "url": "https://community.qlik.com/t5/Release-Notes/Qlik-Sense-Enterprise-on-Windows-November-2021-Initial-Release/ta-p/1856531"
    },
    {
      "type": "WEB",
      "url": "https://csirt.divd.nl/CVE-2022-0564"
    },
    {
      "type": "WEB",
      "url": "https://csirt.divd.nl/DIVD-2021-00021"
    },
    {
      "type": "WEB",
      "url": "https://csirt.divd.nl/cases/DIVD-2021-00021"
    },
    {
      "type": "WEB",
      "url": "https://csirt.divd.nl/cves/CVE-2022-0564"
    }
  ],
  "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-R78M-94WM-V7CV

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-04-04 05:29
VLAI
Details

Under certain circumstances a C•CURE Portal user could enumerate user accounts in C•CURE 9000 version 2.90 and prior versions. This issue affects: C•CURE 9000 2.90 and earlier version 2.90 and prior versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-36201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-204"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-11T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Under certain circumstances a C\u2022CURE Portal user could enumerate user accounts in C\u2022CURE 9000 version 2.90 and prior versions. This issue affects: C\u2022CURE 9000 2.90 and earlier version 2.90 and prior versions.",
  "id": "GHSA-r78m-94wm-v7cv",
  "modified": "2024-04-04T05:29:18Z",
  "published": "2023-07-06T19:24:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36201"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-284-03"
    },
    {
      "type": "WEB",
      "url": "https://www.johnsoncontrols.com/cyber-solutions/security-advisories"
    }
  ],
  "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"
    }
  ]
}

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.