importModule function in MISP ignores per-organisation import module restrictions
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| misp | misp | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Misp | Misp |
|
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.351% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Misp
Misp misp |
|
| Vendors & Products |
Misp
Misp misp |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | MISP’s importModule() path used getEnabledModule() to resolve a single import module by name, but this lookup did not enforce the per-organisation module restriction checked by getEnabledModules(). As a result, an authenticated user from an organisation that was not allowed to use a module restricted via Plugin.Import_<module>_restrict could still invoke that import module directly if they knew its name. This could allow unauthorised access to restricted import-module functionality and, depending on the module and the user’s event permissions, may allow unauthorised import or modification of event data through a module that should have been unavailable to the user’s organisation. | |
| Title | importModule function in MISP ignores per-organisation import module restrictions | |
| Weaknesses | CWE-863 | |
| References |
| |
| Metrics |
cvssV4_0
|