Proof of concept for exploitation of the vulnerability described in CVE-2025-11554, which concerns the possibility of a privilege escalation during arbitrary requests to user types endpoints in the i-Educar software.

Users without the necessary privileges to change user types can modify the permissions of registered user types through an arbitrary request to the endpoint responsible for this action. This allows low-privileged users to escalate their privileges by granting maximum permissions to the user type they are associated with, compromising all sections of the application.

To demonstrate the vulnerability, we will simulate an attack path that could be used in a real exploitation scenario. First, we have the user Usuário sem Privilégios, who is associated with the Baixíssimo user type.

The Baixíssimo user type has no associated privileges and is assigned the lowest access level, Biblioteca, which has the level 8.

For the purposes of this demonstration, we can see that the permissions for editing user types are disabled for this role, meaning that users associated with it should not be able to view, create/edit, or delete user types.

Upon logging in as the Usuário sem Privilégios, we can confirm that no permissions are assigned, as no sections are available to him.

The first step in the privilege escalation process is to identify the user’s assigned user type. In various responses to requests that return rendered HTML documents from the application, this information can be found in the dataLayer variable, located within the first script element of the document. We can verify this information by accessing the application's home page, for example. In this demonstration, Burp Suite will be used for request analysis and manipulation.

After identifying the user type associated with the current user, the next step is to determine its identifier stored in the database. To achieve this, the endpoint /usuarios/tipos/<cod_tipo_usuario> should be used. Since user type identifiers are numeric and sequential, it is possible to enumerate all stored user types until the one associated with the current user is found.

The user type identified by 1, for example, is the administrative user type, Administrador, by default.

In the application's response, we can see the permissions associated with the user type in the processes object. Each specific section is identified by a unique numeric identifier, and the user type's access level to that section is determined by the numbers 0, 1, 2, or 3:

0. No actions allowed.
1. Can only view information in the section.
2. Can view, create new records, and edit existing records in the section.
3. Can view, create new records, edit, and delete existing records in the section.

We can observe that the administrative user type has access level 3 for all sections.

When requesting the user type with identifier 2, we see that it corresponds to the user type associated with the current user. This user type has an access level of 0 for all sections.

With all this in mind, we can proceed with the privilege escalation. To do so, a POST request must be sent to the same endpoint, containing the user type identifier corresponding to the identifier of the user type associated with the current user. The request body should include the parameters _method, name, level, description, and processes. Not all required values are immediately understandable, but since this is an open-source project, the correct structure of the request could easily be discovered through code review or manual testing on a local instance.

In the request below, we modify the access level for all sections to maximum access (3) and change the user type from Biblioteca to Poli-institucional (level parameter set to value 1). This means the user would gain access to all registered institutions, not just the one associated with it during its creation.

After this, upon reloading the home page, we can confirm that the previously permissionless user now has all the available privileges in the context of the application, granted arbitrarily.

The routes for the vulnerable endpoints can be found in the routes/web.php file.

The vulnerable methods used by these routes can be found in the app/Http/Controllers/AccessLevelController.php file. These methods do not perform a permission check on the requesting user before executing the requested actions on user types.

This software is used as a school management solution across various public institutions. Each instance potentially contains various types of sensitive information about registered users and students, such as identification documents and medical records (medical conditions). In a scenario where a low-privileged malicious user or an attacker-controlled account exploits this vulnerability, the confidentiality, integrity, and availability of these records would be at risk. A quick security assessment of the project would reveal this weakness.