关联漏洞
标题：
i-Educar 安全漏洞
(CVE-2025-11554)
描述：i-Educar是Portábilis开源的一个免费教育软件。 i-Educar 2.9.10及之前版本存在安全漏洞，该漏洞源于文件app/Http/Controllers/AccessLevelController.php中用户类型处理组件存在权限继承不当，可能导致远程攻击。
描述
Proof of concept for exploitation of the vulnerability described in CVE-2025-11554, which concerns the possibility of a privilege escalation through arbitrary requests to user types change endpoint in the i-Educar software.
介绍
# Portabilis i-Educar >= 2.1.13 Privilege Escalation Through Arbitrary Request to User Type Change Endpoint
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.
### Description
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.
### Proof of Concept
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.
### Vulnerable Code
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.
### Impact
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.
文件快照
[4.0K] /data/pocs/001b5e4276c2e07d07401bc286440788629c6cc6
├── [5.3K] exploit.py
├── [1.0K] LICENSE
├── [6.8K] README.md
└── [ 928] util.py
0 directories, 4 files
备注
1. 建议优先通过来源进行访问。
2. 如果因为来源失效或无法访问，请发送邮箱到 f.jinxu#gmail.com 索取本地快照（把 # 换成 @）。
3. 神龙已为您对POC代码进行快照，为了长期维护，请考虑为本地POC付费，感谢您的支持。