- SSRF in rule package process (CVE-2026-41195, GHSA-92fh-26qf-r8rg)
Full changelog
This release, v1.4.13, is a security release to fix a security issue in the rule package process.
- Fixed an SSRF security issue in the rule package process, found and reported by @pyuysig, Yuming Zhang, and Song Li of Zhejiang University via the security advisories (CVE-2026-41195, GHSA-92fh-26qf-r8rg).
- Updated the translations for multiple languages.
We're thankful for the analysis and reporting by @pyuysig, Yuming Zhang, and Song Li. Thank you for using the security advisories to report the issue to us in private. We're also thankful for all other contributions, like translations.
We recommend to update to v1.4.13 as soon as you can.
Details of the security issue
Description of the security issue
The rule package process allowed redirects and accessing private networks. This can be used to mount an attack on mosparo, especially via the APIs and the web cron job routes. With this method, an attacker can bypass the allowlists configured in mosparo (Administration -> Security settings) and make requests to these routes, even if the allowlists protect them.
Risk assessment
The risk of this security issue in the rule package process is manageable. The attacker cannot use this method to obtain any information from mosparo. All routes except one are protected by authentication. The only directly exposed API is the health check, which provides no data other than the system status. The attacker can only request a route; the response from the request is not visible to the user. The biggest issues with this security issue are two things:
- It is possible to map the routes and therefore detect the version of a mosparo installation.
- It is possible to overload the server if the web cron job is active and the attacker knows its secret key.
For an attacker to use this security issue, the following requirements need to be met:
- The attacker needs a non-administrative user in your mosparo installation with the
OwnerorEditorrole. Administrative users (users with the "Is administrator" role) can already see all this information in the administration area and gain no benefit from this method. - The allowlists need to be configured in the Administration -> Security settings. Otherwise, the routes are exposed to the internet anyway, and there is no benefit in using this security issue (except for accessing the health check API).
- You need to have enabled the web cron job, and the attacker needs to know the secret key for it; otherwise, overloading the web server by calling it is not possible.
Changes to mitigate the security issue
The following changes resolve the security issue:
- Redirects are no longer followed, and private networks are no longer accessible by the rule package process. This solves the problem completely because, for the attack method, the process must follow the redirects.
- A non-administrative user will no longer see the exact error message when adding a rule package. The user will see an error message, but the message is the same across all error cases.
- A minimum refresh interval of 1 hour is applied to all rule packages, making this attack method even more unusable.
It is possible to allow redirects and access to private networks, and to adjust the minimum refresh interval using newly added environment variables.
With the release of version 1.4.13, we're applying new default values that prevent redirects and private network access, enforce a minimum refresh interval, and replace specific error messages with general ones for non-administrative users.
