Inconsistent security controls

 This vulnerability highlights a critical security design flaw known as inconsistent security controls, where different parts of an application apply different rules for authentication and authorization, allowing an attacker to chain weak logic together to gain elevated privileges.

The attack begins by discovering a hidden administrative endpoint using a content discovery feature in Burp Suite. The /admin path is not exposed through normal navigation but is still accessible on the server. When directly browsing to /admin, access is denied. However, the response reveals an important detail: only users with a specific corporate email domain (e.g., @dontwannacry.com) are permitted to access the admin panel. This immediately suggests that access control is being partially based on a user-controlled attribute (email domain), which is a weak and unsafe design choice.

The next step involves analyzing the registration process. The application instructs that employees should register using a company email address, but this restriction is not enforced server-side. Instead, any email format is accepted, and the user can register using a lab-provided external email domain. After registration, the user receives a confirmation email and successfully logs in as a standard user. At this stage, there is no elevated access, but the system has already established an important inconsistency: it suggests a trusted domain requirement but does not enforce it during account creation.

The key exploitation point appears in the account settings functionality. After logging in, the user is allowed to update their email address without restriction. This is a critical issue because the application later uses the email domain as a trust indicator for admin access. By changing the email address to anything@dontwannacry.com, the attacker effectively satisfies the condition checked by the admin authorization logic. Importantly, there is no additional verification such as re-authentication, domain ownership validation, or email confirmation for the new address.

Once the email is updated, the application incorrectly treats the user as a trusted internal employee. As a result, access to the /admin panel is granted. This demonstrates a classic case of inconsistent enforcement of security rules, where one part of the system (admin authorization) relies on assumptions about email domain, while another part (registration and profile update) allows unrestricted modification of that same attribute. The mismatch between these components creates a privilege escalation path.

Inside the admin panel, the attacker gains access to privileged functionality, including the ability to delete other users (such as the user “carlos”), which confirms full exploitation of the vulnerability. This is not a brute force or injection-based attack, but a logical abuse of trust assumptions embedded in the application’s design.

The root cause of this vulnerability is the reliance on user-controlled data for authorization decisions, combined with inconsistent validation across different workflows. The system treats the email domain as a security boundary but fails to enforce it consistently or securely. A secure implementation would use server-side role-based access control (RBAC), where privileges are assigned independently of user-editable fields. Email addresses should never be used as the sole determinant of authorization.

This vulnerability demonstrates how inconsistent logic between registration, profile updates, and access control can lead to full privilege escalation, even when no traditional security mechanism is directly broken.