Résumé
Paymenter doesn't reset email verification status after email change
Détails de l’avis
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.
Références
Vulnérabilités liées
Tout Supply chain →- CRITICALCVE-2026-46488
motionEye: Authentication possible via password hash
- CRITICALSC-GHA-OIDC-MISCONFIG-2021
This class covers overly permissive cloud IAM trust policies that federate with GitHub's OIDC provider (token.actions.githubusercontent.com) but fail to constrain which workload may assume the role. The cloud role validates the OIDC token but checks only the audience claim (for example sts.amazonaws.com) while omitting the token.actions.githubusercontent.com:sub condition, or it uses a broad wildcard such as repo:org/* or a StringLike pattern instead of StringEquals, so any branch, any fork, or even an attacker-owned repository can mint a valid GitHub OIDC token and exchange it for cloud credentials. Because the sub claim encodes repository, branch, tag, and environment, dropping or loosening it removes the only binding between the role and the intended pipeline, yielding full assumption of the trusted role. Tinder Security Labs documented this in their AWS OIDC research, finding multiple real AWS roles assumable from unauthorized repositories due to missing subject validation, with the successful assumptions visible in CloudTrail. GitHub's OIDC support and the configure-aws-credentials path shipped in 2021, making this a long-standing systemic configuration risk.
- CRITICALSC-KASEYA-VSA-2021
On 2 July 2021, the Friday before the US holiday weekend, the REvil ransomware gang exploited a chain of zero-day flaws in Kaseya VSA, starting with CVE-2021-30116 (an unauthenticated credential leak), in a remote-monitoring-and-management tool used by managed service providers. By abusing VSA's trusted software-deployment mechanism, REvil pushed its encryptor through roughly 50 to 60 MSPs down to about 1,500 of their downstream business customers in one cascading supply-chain hit, including Sweden's Coop grocery chain, which closed about 800 stores. REvil demanded $70 million for a universal decryptor; a decryptor key was ultimately obtained and distributed without payment. It is the lesson that the management tools with the most reach are the highest-value targets and need the strongest controls.
- HIGHCVE-2026-52801
Gogs has the ability to import local repositories via Mirror Settings
- HIGHCVE-2026-52800
Gogs Vulnerable to CSRF Leading to Organization Owner Takeover
- HIGHCVE-2026-52799
Gogs Missing Authorization in Attachment Download