GHSA-rv89-wch8-c574
MEDIUMPaymenter doesn't reset email verification status after email change
Blast Radius
paymenter/paymenterReal-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
The email update functionality fails to invalidate the existing verification state when a user changes their email address, allowing a verified account to retain its verified status after switching to an unverified or unowned email address.
Technical Details
When a user updated their email address, the system did not reset or revalidate the associated email verification status. As a result, the verification column remained set to “true” even after the email address was changed.
This allowed an attacker to:
- Verify an account using a legitimate email address
- Change the account email to an arbitrary or unowned address
- Retain the verified status without re-confirmation of the new email
No verification challenge or confirmation was required for the newly assigned email address.
Impact
This vulnerability allows a user to associate a verified account with an email address they do not control, this may result in:
- Misrepresentation of email ownership
- Bypass of verification-based trust assumptions
- Potential abuse of features gated behind verified status
No direct unauthorized access to other users accounts or data is possible through this issue alone.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | paymenter/paymenter | all versions | 1.5.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for paymenter/paymenter. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update paymenter/paymenter to 1.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rv89-wch8-c574 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rv89-wch8-c574 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rv89-wch8-c574. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-rv89-wch8-c574 in your dependencies?
O3 detects GHSA-rv89-wch8-c574 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.