### 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.
### 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.
Update paymenter/paymenter to 1.5.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanPaymenter doesn't reset email verification status after email change affects paymenter/paymenter (composer). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| paymenter/paymentercomposer | <1.5.0 | 1.5.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate paymenter/paymenter to 1.5.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanPaymenter doesn't reset email verification status after email change affects paymenter/paymenter (composer). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| paymenter/paymentercomposer | <1.5.0 | 1.5.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard