Nezha EUVD-2026-88024

Requires a valid authenticated session on the Nezha dashboard (PR:L) to reach GET /api/v1/profile; exploitation is limited to accounts on Nezha versions before 2.2.7. The disclosed value is a bcrypt hash, so actual credential compromise is further gated by the strength of the underlying password and the attacker's offline cracking resources (reflected as AC:H/AT:P) - strong/random passwords are effectively uncrackable. No user interaction beyond the attacker's own request is needed, and no special non-default configuration is required.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor's CVSS 4.0 score of 2.3 (AV:N/AC:H/AT:P/PR:L/UI:N/VC:L only) aligns with the description: exploitation requires an already-authenticated account (PR:L), yields only limited confidentiality impact (VC:L), and carries no integrity or availability impact. AC:H/AT:P reflect the practical reality that the leaked data is a bcrypt hash - a deliberately slow, salted KDF - so 'exploitation' really means an offline password-cracking campaign whose success depends entirely on password weakness and attacker compute, not a direct credential grab. No EPSS score, KEV listing, or public exploit code is present in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis.' There is no SSVC data supplied. The one real aggravating factor the description raises - that cracking happens offline with no rate limiting or audit trail - is inherent to any hash disclosure and does not raise the base severity. Net: a real but minor CWE-522 credential-exposure hardening bug, not an urgent threat. Note the description implies the endpoint returns the authenticated caller's own hash; if it instead returns other users' hashes, impact would be higher - this distinction is not fully clear from the input and should be verified against the GHSA advisory.

An authenticated Nezha user (or an attacker who has phished/reused one low-privilege dashboard credential) calls GET /api/v1/profile and receives the bcrypt-hashed password in the response body. They save the hash and run an offline cracking tool (e.g. hashcat) against it with no rate limiting or logging on the server side, hoping the underlying password is weak enough to recover and reuse. No public exploit code is referenced in the available intelligence.