Known affected by Account Takeover via Password Reset Token LeakageGHSA-78wq-6gcv-w28r
CRITICALFix: idno/known@8439a07GHSA-78wq-6gcv-w28r is a critical-severity (CVSS 9.8) Information Exposure vulnerability in idno/known. A fix is available for idno/known — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-78wq-6gcv-w28r.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
idno/knownReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A Critical Broken Authentication vulnerability exists in Known 1.6.2. The application leaks the password reset token within a hidden HTML input field on the password reset page. This allows any unauthenticated attacker to retrieve the reset token for any user by simply querying the user's email, leading to full Account Takeover (ATO) without requiring access to the victim's email inbox.
Details
The vulnerability occurs within the password reset flow. When a reset is requested, the application generates a verification code. However, the subsequent reset page (/account/password/reset/) incorrectly reflects this code back to the client in the HTML source code.
Specifically, the sensitive token is embedded in: <input type="hidden" name="code" value="[SECRET_TOKEN]">
Because this page is accessible via a GET request using the victim's email as a parameter, an attacker can programmatically extract the token.
PoC
- The attacker asks for a password reset for the victim
-
The attacker makes the following curl command on the terminal using the victim's email, and is able to get the code that was sent as an hidden field in the HTML.
<img width="917" height="220" alt="image(2)" src="https://github.com/user-attachments/assets/af89ba3b-de56-4437-84b3-c1feb56d2348" /> -
With this code, the attacker is able to use it in order to reset the victim password.
<img width="1335" height="711" alt="image(3)" src="https://github.com/user-attachments/assets/498b8a2e-9eb2-4b50-bc35-26b0f2764c8d" />
- The attacker is able to login with the new password.
Impact
- An attacker can compromise any account on the platform, including administrative accounts, resulting in total loss of Confidentiality, Integrity, and Availability.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | idno/known | all versions | 1.6.3composer require idno/known:^1.6.3 |
Affected Products
knownwithknownDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for idno/known, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update idno/known to 1.6.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-78wq-6gcv-w28r is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Frequently Asked Questions
Is GHSA-78wq-6gcv-w28r in your dependencies?
Find it across Packagist, including transitive dependencies.