Common Weakness Enumeration
CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
16578 vulnerabilities reference this CWE, most recent first.
GCVE-1-2026-20166 (CVE-2026-78380)
Vulnerability from gna-1 – Published: 2026-08-24 13:26 – Updated: 2026-08-24 13:26
VLAI
EPSS
VEX
Title
Private Group and Market Posts Disclosed Through Public Notification Channels in RansomLook
Summary
RansomLook fails to enforce the privacy status of ransomware groups and markets when distributing newly collected victim posts to external notification channels. The post-processing logic checks whether an individual post is marked private but does not verify whether the group or market to which the post belongs is configured as private.
As a result, newly parsed victim information associated with a private group or market may be automatically published through enabled Rocket.Chat, Mastodon, Bluesky, and e-mail notification channels despite the entity being explicitly configured to prevent public disclosure.
A similar issue affects the public MISP feed. The feed previously determined privacy using groupinfo(), which only queries the group database. Consequently, victim information associated with private markets could be added to the public MISP feed because the corresponding market privacy flag was not evaluated.
An attacker or other unauthorized party able to access these public notification channels or the MISP feed may obtain victim information that was intended to remain private. Depending on the collected data, this may disclose victim names, ransomware activity, incident information, or other information associated with privately monitored groups and markets.
The fix introduces a common is_private_entity() check covering both groups and markets and prevents private entity posts from being distributed through external notification channels or the public MISP feed. Internal storage and dashboard alerting remain unaffected.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/RansomLook/RansomLook/commit/1… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| ransomlook | ransomlook |
Affected:
0 , ≤ 2.0.0
(semver)
|
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "ransomlook",
"repo": "https://github.com/RansomLook/RansomLook/",
"vendor": "ransomlook",
"versions": [
{
"lessThanOrEqual": "2.0.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Fafner [_KeyZee_]"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRansomLook fails to enforce the privacy status of ransomware groups and markets when distributing newly collected victim posts to external notification channels. The post-processing logic checks whether an individual post is marked private but does not verify whether the group or market to which the post belongs is configured as private.\u003c/p\u003e\u003cp\u003eAs a result, newly parsed victim information associated with a private group or market may be automatically published through enabled Rocket.Chat, Mastodon, Bluesky, and e-mail notification channels despite the entity being explicitly configured to prevent public disclosure.\u003c/p\u003e\u003cp\u003eA similar issue affects the public MISP feed. The feed previously determined privacy using \u003ccode\u003egroupinfo()\u003c/code\u003e, which only queries the group database. Consequently, victim information associated with private markets could be added to the public MISP feed because the corresponding market privacy flag was not evaluated.\u003c/p\u003e\u003cp\u003eAn attacker or other unauthorized party able to access these public notification channels or the MISP feed may obtain victim information that was intended to remain private. Depending on the collected data, this may disclose victim names, ransomware activity, incident information, or other information associated with privately monitored groups and markets.\u003c/p\u003e\u003cp\u003eThe fix introduces a common \u003ccode\u003eis_private_entity()\u003c/code\u003e check covering both groups and markets and prevents private entity posts from being distributed through external notification channels or the public MISP feed. Internal storage and dashboard alerting remain unaffected.\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "RansomLook fails to enforce the privacy status of ransomware groups and markets when distributing newly collected victim posts to external notification channels. The post-processing logic checks whether an individual post is marked private but does not verify whether the group or market to which the post belongs is configured as private.\n\nAs a result, newly parsed victim information associated with a private group or market may be automatically published through enabled Rocket.Chat, Mastodon, Bluesky, and e-mail notification channels despite the entity being explicitly configured to prevent public disclosure.\n\nA similar issue affects the public MISP feed. The feed previously determined privacy using groupinfo(), which only queries the group database. Consequently, victim information associated with private markets could be added to the public MISP feed because the corresponding market privacy flag was not evaluated.\n\nAn attacker or other unauthorized party able to access these public notification channels or the MISP feed may obtain victim information that was intended to remain private. Depending on the collected data, this may disclose victim names, ransomware activity, incident information, or other information associated with privately monitored groups and markets.\n\nThe fix introduces a common is_private_entity() check covering both groups and markets and prevents private entity posts from being distributed through external notification channels or the public MISP feed. Internal storage and dashboard alerting remain unaffected."
}
],
"impacts": [
{
"capecId": "CAPEC-115",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-115 Authentication Bypass"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/RansomLook/RansomLook/commit/133cbeab3abdd64c22b02165c6505bb3e53698cc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Private Group and Market Posts Disclosed Through Public Notification Channels in RansomLook",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20166"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-78380",
"datePublished": "2026-08-24T13:26:41.992725Z",
"dateReserved": "2026-08-24T13:26:52.008Z",
"dateUpdated": "2026-08-24T13:26:52.078718Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20166"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GCVE-1-2026-20160 (CVE-2026-73140)
Vulnerability from gna-1 – Published: 2026-08-11 07:17 – Updated: 2026-08-11 07:38
VLAI
EPSS
VEX
Title
cti-transmute Evaluation Report Exports Expose Private Comments and Author Information
Summary
Affected versions of cti-transmute fail to apply comment-level access-control rules when generating evaluation report exports. Although normal comment retrieval filters comments according to conversion visibility, comment privacy, ownership, authorship, and administrative privileges, build_evaluation_report() previously included all evaluation comments without applying those rules.
Consequently, a user who was authorized to view a conversion could export its evaluation report as Markdown or PDF and obtain private evaluation comments that should only have been visible to the conversion owner, the comment author, or an administrator. The leaked report data also contained the comment author's name. The fix passes the requesting user into the report builder and filters every evaluation comment using the shared access.can_see_comment() authorization function.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/MISP/cti-transmute/commit/5dbd… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| MISP | cti-transmute |
Affected:
0 , ≤ 1.4.0
(semver)
|
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "cti-transmute",
"repo": "https://github.com/MISP/cti-transmute",
"vendor": "MISP",
"versions": [
{
"lessThanOrEqual": "1.4.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Christian Studer"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffected versions of cti-transmute fail to apply comment-level access-control rules when generating evaluation report exports. Although normal comment retrieval filters comments according to conversion visibility, comment privacy, ownership, authorship, and administrative privileges, \u003ccode\u003ebuild_evaluation_report()\u003c/code\u003e previously included all evaluation comments without applying those rules.\u003c/p\u003e\n\u003cp\u003eConsequently, a user who was authorized to view a conversion could export its evaluation report as Markdown or PDF and obtain private evaluation comments that should only have been visible to the conversion owner, the comment author, or an administrator. The leaked report data also contained the comment author\u0027s name. The fix passes the requesting user into the report builder and filters every evaluation comment using the shared \u003ccode\u003eaccess.can_see_comment()\u003c/code\u003e authorization function.\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "Affected versions of cti-transmute fail to apply comment-level access-control rules when generating evaluation report exports. Although normal comment retrieval filters comments according to conversion visibility, comment privacy, ownership, authorship, and administrative privileges, build_evaluation_report() previously included all evaluation comments without applying those rules.\n\n\nConsequently, a user who was authorized to view a conversion could export its evaluation report as Markdown or PDF and obtain private evaluation comments that should only have been visible to the conversion owner, the comment author, or an administrator. The leaked report data also contained the comment author\u0027s name. The fix passes the requesting user into the report builder and filters every evaluation comment using the shared access.can_see_comment() authorization function."
}
],
"impacts": [
{
"capecId": "CAPEC-87",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-87 Forceful Browsing"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/cti-transmute/commit/5dbd19b39a61eab793586731f1a80d8c38907c42"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "cti-transmute Evaluation Report Exports Expose Private Comments and Author Information",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20160"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-73140",
"datePublished": "2026-08-11T07:17:00.000Z",
"dateReserved": "2026-08-11T07:18:00.000Z",
"dateUpdated": "2026-08-11T07:38:30.259049Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20160"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2026-20155 (GCVE-0-2026-20155)
Vulnerability from cvelistv5 – Published: 2026-04-01 16:29 – Updated: 2026-04-01 18:19
VLAI
EPSS
VEX
Title
Cisco Evolved Programmable Network Manager Improper Authorization Vulnerability
Summary
A vulnerability in the web-based management interface of Cisco Evolved Programmable Network Manager (EPNM) could allow an authenticated, remote attacker with low privileges to access sensitive information that they are not authorized to access.
This vulnerability is due to improper authorization checks on a REST API endpoint of an affected device. An attacker could exploit this vulnerability by querying the affected endpoint. A successful exploit could allow the attacker to view session information of active Cisco EPNM users, including users with administrative privileges, which could result in the affected device being compromised.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-04-01 18:19 UTC
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Cisco | Cisco Evolved Programmable Network Manager (EPNM) |
Affected:
7.1.1
Affected: 7.1.2.1 Affected: 7.1.3 Affected: 7.1.2 Affected: 7.1.0 Affected: 8.0.0 Affected: 8.0.0.1 Affected: 7.1.3.1 Affected: 7.1.4 Affected: 8.1.0 Affected: 8.1.1 Affected: 8.0.1 Affected: 7.1.4.1 Affected: 8.0.1.1 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-20155",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-01T18:19:08.632246Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-01T18:19:17.434Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unknown",
"product": "Cisco Evolved Programmable Network Manager (EPNM)",
"vendor": "Cisco",
"versions": [
{
"status": "affected",
"version": "7.1.1"
},
{
"status": "affected",
"version": "7.1.2.1"
},
{
"status": "affected",
"version": "7.1.3"
},
{
"status": "affected",
"version": "7.1.2"
},
{
"status": "affected",
"version": "7.1.0"
},
{
"status": "affected",
"version": "8.0.0"
},
{
"status": "affected",
"version": "8.0.0.1"
},
{
"status": "affected",
"version": "7.1.3.1"
},
{
"status": "affected",
"version": "7.1.4"
},
{
"status": "affected",
"version": "8.1.0"
},
{
"status": "affected",
"version": "8.1.1"
},
{
"status": "affected",
"version": "8.0.1"
},
{
"status": "affected",
"version": "7.1.4.1"
},
{
"status": "affected",
"version": "8.0.1.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "A vulnerability in the web-based management interface of Cisco Evolved Programmable Network Manager (EPNM) could allow an authenticated, remote attacker with low privileges to access sensitive information that they are not authorized to access.\r\n\r\nThis vulnerability is due to improper authorization checks on a REST API endpoint of an affected device.\u0026nbsp;An attacker could exploit this vulnerability by querying the affected endpoint. A successful exploit could allow the attacker to view session information of active Cisco EPNM users, including users with administrative privileges, which could result in the affected device being compromised."
}
],
"exploits": [
{
"lang": "en",
"value": "The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities that are described in this advisory."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "cvssV3_1"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "Missing Authorization",
"lang": "en",
"type": "cwe"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-01T16:29:12.891Z",
"orgId": "d1c1063e-7a18-46af-9102-31f8928bc633",
"shortName": "cisco"
},
"references": [
{
"name": "cisco-sa-epnm-improp-auth-mUwFWUU3",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-epnm-improp-auth-mUwFWUU3"
}
],
"source": {
"advisory": "cisco-sa-epnm-improp-auth-mUwFWUU3",
"defects": [
"CSCwp27059"
],
"discovery": "EXTERNAL"
},
"title": "Cisco Evolved Programmable Network Manager Improper Authorization Vulnerability"
}
},
"cveMetadata": {
"assignerOrgId": "d1c1063e-7a18-46af-9102-31f8928bc633",
"assignerShortName": "cisco",
"cveId": "CVE-2026-20155",
"datePublished": "2026-04-01T16:29:12.891Z",
"dateReserved": "2025-10-08T11:59:15.386Z",
"dateUpdated": "2026-04-01T18:19:17.434Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1-2026-20150 (CVE-2026-78387)
Vulnerability from gna-1 – Published: 2026-08-24 14:03 – Updated: 2026-08-24 14:04
VLAI
EPSS
VEX
Title
RansomLook Missing Authorization in Web Configuration Editor Allows Application Configuration Modification
Summary
RansomLook contains an authorization weakness in the web-based configuration editor exposed through the /admin/config endpoint. The endpoint requires an authenticated session but does not perform an explicit privilege or administrator authorization check before allowing access to configuration-management functionality.
An authenticated low-privileged user able to access the endpoint can submit crafted configuration values that are written directly to the application's config/generic.json file. The affected functionality permits modification of configuration sections including notification, LDAP, SMTP, and general application settings. Successful exploitation could therefore allow an attacker to alter security-sensitive application behavior, redirect integrations or notifications, modify authentication-related configuration, disrupt external services, or render the RansomLook installation unavailable.
The configuration editor also operated on a configuration file containing sensitive values such as passwords, tokens, secrets, and API keys. Although the affected version contains logic intended to prevent recognized secret values from being returned to the browser, exposing configuration management through insufficiently authorized web functionality significantly increases the impact of a compromised or low-privileged account.
The patch resolves the issue by completely removing the /admin/config route and associated configuration-editing interface, preventing application configuration from being modified through the web UI.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/RansomLook/RansomLook/commit/d… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| ransomlook | ransomlook |
Affected:
0 , ≤ 2.0.0
(semver)
|
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "ransomlook",
"repo": "https://github.com/RansomLook/RansomLook",
"vendor": "ransomlook",
"versions": [
{
"lessThanOrEqual": "2.0.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Fafner [_KeyZee_]"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRansomLook contains an authorization weakness in the web-based configuration editor exposed through the \u003ccode\u003e/admin/config\u003c/code\u003e endpoint. The endpoint requires an authenticated session but does not perform an explicit privilege or administrator authorization check before allowing access to configuration-management functionality.\u003c/p\u003e\u003cp\u003eAn authenticated low-privileged user able to access the endpoint can submit crafted configuration values that are written directly to the application\u0027s \u003ccode\u003econfig/generic.json\u003c/code\u003e file. The affected functionality permits modification of configuration sections including notification, LDAP, SMTP, and general application settings. Successful exploitation could therefore allow an attacker to alter security-sensitive application behavior, redirect integrations or notifications, modify authentication-related configuration, disrupt external services, or render the RansomLook installation unavailable.\u003c/p\u003e\u003cp\u003eThe configuration editor also operated on a configuration file containing sensitive values such as passwords, tokens, secrets, and API keys. Although the affected version contains logic intended to prevent recognized secret values from being returned to the browser, exposing configuration management through insufficiently authorized web functionality significantly increases the impact of a compromised or low-privileged account.\u003c/p\u003e\u003cp\u003eThe patch resolves the issue by completely removing the \u003ccode\u003e/admin/config\u003c/code\u003e route and associated configuration-editing interface, preventing application configuration from being modified through the web UI.\u003c/p\u003e\u003ch2\u003e\u003c/h2\u003e\u003cbr\u003e"
}
],
"value": "RansomLook contains an authorization weakness in the web-based configuration editor exposed through the /admin/config endpoint. The endpoint requires an authenticated session but does not perform an explicit privilege or administrator authorization check before allowing access to configuration-management functionality.\n\nAn authenticated low-privileged user able to access the endpoint can submit crafted configuration values that are written directly to the application\u0027s config/generic.json file. The affected functionality permits modification of configuration sections including notification, LDAP, SMTP, and general application settings. Successful exploitation could therefore allow an attacker to alter security-sensitive application behavior, redirect integrations or notifications, modify authentication-related configuration, disrupt external services, or render the RansomLook installation unavailable.\n\nThe configuration editor also operated on a configuration file containing sensitive values such as passwords, tokens, secrets, and API keys. Although the affected version contains logic intended to prevent recognized secret values from being returned to the browser, exposing configuration management through insufficiently authorized web functionality significantly increases the impact of a compromised or low-privileged account.\n\nThe patch resolves the issue by completely removing the /admin/config route and associated configuration-editing interface, preventing application configuration from being modified through the web UI."
}
],
"impacts": [
{
"capecId": "CAPEC-122",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-122 Privilege Abuse"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "HIGH",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/RansomLook/RansomLook/commit/d411ff51446e9e8b04e15567b46d53e86a3116dd"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "RansomLook Missing Authorization in Web Configuration Editor Allows Application Configuration Modification",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20150"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-78387",
"datePublished": "2026-08-24T14:03:49.792546Z",
"dateReserved": "2026-08-24T14:04:08.566Z",
"dateUpdated": "2026-08-24T14:04:08.948852Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20150"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GCVE-1-2026-20143 (CVE-2026-85533)
Vulnerability from gna-1 – Published: 2026-09-04 08:53 – Updated: 2026-09-04 08:53
VLAI
EPSS
VEX
Title
MISP Sharing Group Authorization Bypass via Omitted Distribution Parameter
Summary
An authorization flaw in MISP allowed an authenticated user to submit a sharing_group_id without verifying that the user was authorized to use the referenced Sharing Group.
In several attribute and Galaxy Cluster creation and editing workflows, validation of the submitted Sharing Group was performed only when the request explicitly set the distribution field to 4 ("Sharing Group"). An attacker could therefore craft a request containing a sharing_group_id while omitting the distribution parameter, or otherwise avoiding the distribution == 4 condition, causing the Sharing Group authorization check to be skipped.
This could allow a user with permission to create or modify the affected MISP objects to associate data with a Sharing Group that they are not authorized to use. Depending on the affected object's existing distribution settings and subsequent processing, this could bypass intended information-sharing boundaries and result in unauthorized placement or distribution of data to members of another Sharing Group.
The issue affected attribute attachment and editing operations as well as Galaxy Cluster creation and editing. The fix ensures that authorization is performed whenever a non-empty sharing_group_id is submitted, independently of the distribution parameter. It also centralizes the authorization decision in SharingGroup::canUse() and explicitly rejects empty Sharing Group identifiers rather than allowing them to be interpreted as an unrestricted query.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/MISP/MISP/commit/9b1363955 | patch |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "misp",
"repo": "https://github.com/MISP/MISP",
"vendor": "misp",
"versions": [
{
"lessThanOrEqual": "2.5.45",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "Andras Iklody"
},
{
"lang": "en",
"type": "finder",
"value": "elhoim (David Andr\u00e9)"
},
{
"lang": "en",
"type": "finder",
"value": "Claude Opus 5 (1M context)"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn authorization flaw in MISP allowed an authenticated user to submit a \u003ccode\u003esharing_group_id\u003c/code\u003e without verifying that the user was authorized to use the referenced Sharing Group.\u003c/p\u003e\u003cp\u003eIn several attribute and Galaxy Cluster creation and editing workflows, validation of the submitted Sharing Group was performed only when the request explicitly set the \u003ccode\u003edistribution\u003c/code\u003e field to \u003ccode\u003e4\u003c/code\u003e (\"Sharing Group\"). An attacker could therefore craft a request containing a \u003ccode\u003esharing_group_id\u003c/code\u003e while omitting the \u003ccode\u003edistribution\u003c/code\u003e parameter, or otherwise avoiding the \u003ccode\u003edistribution == 4\u003c/code\u003e condition, causing the Sharing Group authorization check to be skipped.\u003c/p\u003e\u003cp\u003eThis could allow a user with permission to create or modify the affected MISP objects to associate data with a Sharing Group that they are not authorized to use. Depending on the affected object\u0027s existing distribution settings and subsequent processing, this could bypass intended information-sharing boundaries and result in unauthorized placement or distribution of data to members of another Sharing Group.\u003c/p\u003e\u003cp\u003eThe issue affected attribute attachment and editing operations as well as Galaxy Cluster creation and editing. The fix ensures that authorization is performed whenever a non-empty \u003ccode\u003esharing_group_id\u003c/code\u003e is submitted, independently of the \u003ccode\u003edistribution\u003c/code\u003e parameter. It also centralizes the authorization decision in \u003ccode\u003eSharingGroup::canUse()\u003c/code\u003e and explicitly rejects empty Sharing Group identifiers rather than allowing them to be interpreted as an unrestricted query.\u003c/p\u003e"
}
],
"value": "An authorization flaw in MISP allowed an authenticated user to submit a sharing_group_id without verifying that the user was authorized to use the referenced Sharing Group.\n\nIn several attribute and Galaxy Cluster creation and editing workflows, validation of the submitted Sharing Group was performed only when the request explicitly set the distribution field to 4 (\"Sharing Group\"). An attacker could therefore craft a request containing a sharing_group_id while omitting the distribution parameter, or otherwise avoiding the distribution == 4 condition, causing the Sharing Group authorization check to be skipped.\n\nThis could allow a user with permission to create or modify the affected MISP objects to associate data with a Sharing Group that they are not authorized to use. Depending on the affected object\u0027s existing distribution settings and subsequent processing, this could bypass intended information-sharing boundaries and result in unauthorized placement or distribution of data to members of another Sharing Group.\n\nThe issue affected attribute attachment and editing operations as well as Galaxy Cluster creation and editing. The fix ensures that authorization is performed whenever a non-empty sharing_group_id is submitted, independently of the distribution parameter. It also centralizes the authorization decision in SharingGroup::canUse() and explicitly rejects empty Sharing Group identifiers rather than allowing them to be interpreted as an unrestricted query."
}
],
"impacts": [
{
"capecId": "CAPEC-1",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.6,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/9b1363955"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "MISP Sharing Group Authorization Bypass via Omitted Distribution Parameter",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20143"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-85533",
"datePublished": "2026-09-04T08:53:11.134719Z",
"dateReserved": "2026-09-04T08:53:39.237Z",
"dateUpdated": "2026-09-04T08:53:39.328442Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20143"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GCVE-1-2026-20137 (CVE-2026-78372)
Vulnerability from gna-1 – Published: 2026-08-24 13:09 – Updated: 2026-08-24 13:09
VLAI
EPSS
VEX
Title
RansomLook Missing Authorization Allows Disclosure of Private Group and Ransom Note Data
Summary
RansomLook does not consistently
enforce authorization checks when accessing groups, markets, and ransom
notes marked as private. An unauthenticated or otherwise unauthorized
remote attacker can access information associated with private entities
through several web views and API endpoints.
The affected functionality can
disclose private group or market names, ransom-note content, and
metadata associated with private groups. The /compare
functionality can also be queried directly with the name of a private
entity, allowing an unauthorized user to retrieve information such as
post counts, mirror totals, and uptime even when the entity is excluded
from the normal user interface. The patch explicitly adds a privacy
check before returning this information.
Ransom-note views, search results,
and API endpoints were similarly missing consistent filtering. The fix
introduces normalized private-group identifiers and alias handling, then
rejects or filters notes associated with private groups before
returning them to unauthorized callers.
An attacker can exploit the issue
remotely without authentication or user interaction, resulting in
disclosure of information that was explicitly intended to be restricted
to authorized users.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/RansomLook/RansomLook/commit/d… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| ransomlook | ransomlook |
Affected:
0 , ≤ 2.0.0
(semver)
|
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "ransomlook",
"repo": "https://github.com/RansomLook/RansomLook",
"vendor": "ransomlook",
"versions": [
{
"lessThanOrEqual": "2.0.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Fafner [_KeyZee_]"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRansomLook does not consistently \nenforce authorization checks when accessing groups, markets, and ransom \nnotes marked as private. An unauthenticated or otherwise unauthorized \nremote attacker can access information associated with private entities \nthrough several web views and API endpoints.\u003c/p\u003e\n\u003cp\u003eThe affected functionality can \ndisclose private group or market names, ransom-note content, and \nmetadata associated with private groups. The \u003ccode\u003e/compare\u003c/code\u003e\n functionality can also be queried directly with the name of a private \nentity, allowing an unauthorized user to retrieve information such as \npost counts, mirror totals, and uptime even when the entity is excluded \nfrom the normal user interface. The patch explicitly adds a privacy \ncheck before returning this information. \u003c/p\u003e\n\u003cp\u003eRansom-note views, search results, \nand API endpoints were similarly missing consistent filtering. The fix \nintroduces normalized private-group identifiers and alias handling, then\n rejects or filters notes associated with private groups before \nreturning them to unauthorized callers. \u003c/p\u003e\n\u003cp\u003eAn attacker can exploit the issue \nremotely without authentication or user interaction, resulting in \ndisclosure of information that was explicitly intended to be restricted \nto authorized users.\u003c/p\u003e"
}
],
"value": "RansomLook does not consistently \nenforce authorization checks when accessing groups, markets, and ransom \nnotes marked as private. An unauthenticated or otherwise unauthorized \nremote attacker can access information associated with private entities \nthrough several web views and API endpoints.\n\n\nThe affected functionality can \ndisclose private group or market names, ransom-note content, and \nmetadata associated with private groups. The /compare\n functionality can also be queried directly with the name of a private \nentity, allowing an unauthorized user to retrieve information such as \npost counts, mirror totals, and uptime even when the entity is excluded \nfrom the normal user interface. The patch explicitly adds a privacy \ncheck before returning this information. \n\n\nRansom-note views, search results, \nand API endpoints were similarly missing consistent filtering. The fix \nintroduces normalized private-group identifiers and alias handling, then\n rejects or filters notes associated with private groups before \nreturning them to unauthorized callers. \n\n\nAn attacker can exploit the issue \nremotely without authentication or user interaction, resulting in \ndisclosure of information that was explicitly intended to be restricted \nto authorized users."
}
],
"impacts": [
{
"capecId": "CAPEC-1",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.2,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/RansomLook/RansomLook/commit/dc92d6d5c076bcdbf3476aca42daf0260e8d99d7"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "RansomLook Missing Authorization Allows Disclosure of Private Group and Ransom Note Data",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20137"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-78372",
"datePublished": "2026-08-24T13:09:11.020129Z",
"dateReserved": "2026-08-24T13:09:20.209Z",
"dateUpdated": "2026-08-24T13:09:20.280924Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20137"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GCVE-1-2026-20133 (CVE-2026-81819)
Vulnerability from gna-1 – Published: 2026-08-27 13:20 – Updated: 2026-08-27 13:20
VLAI
EPSS
VEX
Title
Flowintel Missing Authorization Allows Regular API Users to View Other Users’ Task Assignments
Summary
Affected versions of Flowintel expose the /my_assignment/user API endpoint to any authenticated API user. The endpoint accepts a user_id parameter identifying the user whose assignments should be returned, but previously had no role restriction beyond general API authentication.
As a result, a lower-privileged authenticated user could potentially query another user’s assignment information by supplying that user’s identifier.
The fix changes:
method_decorators = [api_required]
to:
method_decorators = [admin_or_org_admin_required, api_required]
so only administrators or organization administrators can perform cross-user assignment queries.
Version impacted =>3.3.0
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/flowintel/flowintel/commit/10e… | patch |
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "flowintel",
"repo": "https://github.com/flowintel/flowintel",
"vendor": "flowintel",
"versions": [
{
"lessThanOrEqual": "3.3.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "remediation developer",
"value": "David Cruciani"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffected versions of Flowintel expose the \u003ccode\u003e/my_assignment/user\u003c/code\u003e API endpoint to any authenticated API user. The endpoint accepts a \u003ccode\u003euser_id\u003c/code\u003e parameter identifying the user whose assignments should be returned, but previously had no role restriction beyond general API authentication.\u003c/p\u003e\n\u003cp\u003eAs a result, a lower-privileged authenticated user could potentially query another user\u2019s assignment information by supplying that user\u2019s identifier.\u003c/p\u003e\n\u003cp\u003eThe fix changes:\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003emethod_decorators = [api_required]\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eto:\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003emethod_decorators = [admin_or_org_admin_required, api_required]\u003c/code\u003e\u003c/p\u003e\u003cp\u003eso only administrators or organization administrators can perform cross-user assignment queries.\u003c/p\u003eVersion impacted =\u0026gt;3.3.0"
}
],
"value": "Affected versions of Flowintel expose the /my_assignment/user API endpoint to any authenticated API user. The endpoint accepts a user_id parameter identifying the user whose assignments should be returned, but previously had no role restriction beyond general API authentication.\n\n\nAs a result, a lower-privileged authenticated user could potentially query another user\u2019s assignment information by supplying that user\u2019s identifier.\n\n\nThe fix changes:\n\n\nmethod_decorators = [api_required]\n\n\nto:\n\n\nmethod_decorators = [admin_or_org_admin_required, api_required]\n\nso only administrators or organization administrators can perform cross-user assignment queries.\n\nVersion impacted =\u003e3.3.0"
}
],
"impacts": [
{
"capecId": "CAPEC-1",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/flowintel/flowintel/commit/10ec32e7baa0fa12ffb83bec36d1b4749a428b5c.patch"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Flowintel Missing Authorization Allows Regular API Users to View Other Users\u2019 Task Assignments",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20133"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-81819",
"datePublished": "2026-08-27T13:20:19.140044Z",
"dateReserved": "2026-08-27T13:20:34.930Z",
"dateUpdated": "2026-08-27T13:20:35.102328Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20133"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GCVE-1-2026-20110 (CVE-2026-88915)
Vulnerability from gna-1 – Published: 2026-09-10 13:03 – Updated: 2026-09-10 13:04
VLAI
EPSS
VEX
Title
MISP Event Template Instantiation Bypasses Sharing Group and Tagging Authorization
Summary
Affected versions of MISP do not consistently enforce the acting user's authorization when instantiating event templates.
For templates using distribution = 4, the template can specify a sharing_group_id. The instantiation path passed that value into event creation without verifying that the user instantiating the template was actually permitted to use the selected sharing group. The commit notes that Event::_add() only performed its own sharing-group authorization in another code path, leaving template instantiation able to write the identifier directly.
The same instantiation path also attached template-specified tags without checking the user's normal tagging permissions. In addition, it hardcoded local => 0, meaning tags marked local_only could be attached globally and consequently propagate through synchronization or export, contrary to their intended restriction.
The fix adds explicit SharingGroup::canUse() authorization for the acting user, applies the same tag-modification checks used by normal event tagging, and ensures local_only tags are attached locally.
Version affected: ≤2.5.45
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/MISP/MISP/commit/3aa3a9a97 | patch |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "MISP",
"repo": "https://github.com/MISP/MISP",
"vendor": "MISP",
"versions": [
{
"lessThanOrEqual": "2.5.45",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Scottish Government - National Cyber Team"
},
{
"lang": "en",
"type": "remediation developer",
"value": "iglocska"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Claude Opus 5 (1M context)"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffected versions of MISP do not consistently enforce the acting user\u0027s authorization when instantiating event templates.\u003c/p\u003e\n\u003cp\u003eFor templates using \u003ccode\u003edistribution = 4\u003c/code\u003e, the template can specify a \u003ccode\u003esharing_group_id\u003c/code\u003e. The instantiation path passed that value into event creation without verifying that the user instantiating the template was actually permitted to use the selected sharing group. The commit notes that \u003ccode\u003eEvent::_add()\u003c/code\u003e only performed its own sharing-group authorization in another code path, leaving template instantiation able to write the identifier directly.\u003c/p\u003e\n\u003cp\u003eThe same instantiation path also attached template-specified tags without checking the user\u0027s normal tagging permissions. In addition, it hardcoded \u003ccode\u003elocal =\u0026gt; 0\u003c/code\u003e, meaning tags marked \u003ccode\u003elocal_only\u003c/code\u003e could be attached globally and consequently propagate through synchronization or export, contrary to their intended restriction.\u003c/p\u003e\n\u003cp\u003eThe fix adds explicit \u003ccode\u003eSharingGroup::canUse()\u003c/code\u003e authorization for the acting user, applies the same tag-modification checks used by normal event tagging, and ensures \u003ccode\u003elocal_only\u003c/code\u003e tags are attached locally.\u003c/p\u003eVersion affected: \u22642.5.45\u003cbr\u003e"
}
],
"value": "Affected versions of MISP do not consistently enforce the acting user\u0027s authorization when instantiating event templates.\n\n\nFor templates using distribution = 4, the template can specify a sharing_group_id. The instantiation path passed that value into event creation without verifying that the user instantiating the template was actually permitted to use the selected sharing group. The commit notes that Event::_add() only performed its own sharing-group authorization in another code path, leaving template instantiation able to write the identifier directly.\n\n\nThe same instantiation path also attached template-specified tags without checking the user\u0027s normal tagging permissions. In addition, it hardcoded local =\u003e 0, meaning tags marked local_only could be attached globally and consequently propagate through synchronization or export, contrary to their intended restriction.\n\n\nThe fix adds explicit SharingGroup::canUse() authorization for the acting user, applies the same tag-modification checks used by normal event tagging, and ensures local_only tags are attached locally.\n\nVersion affected: \u22642.5.45"
}
],
"impacts": [
{
"capecId": "CAPEC-1",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/3aa3a9a97"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "MISP Event Template Instantiation Bypasses Sharing Group and Tagging Authorization",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20110"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-88915",
"datePublished": "2026-09-10T13:03:54.652851Z",
"dateReserved": "2026-09-10T13:04:01.032Z",
"dateUpdated": "2026-09-10T13:04:01.471196Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "GCVE-1-2026-20110"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GCVE-1-2026-20099 (CVE-2026-56424)
Vulnerability from gna-1 – Published: 2026-06-22 12:13 – Updated: 2026-06-22 12:17
VLAI
EPSS
VEX
Title
Broken access control in MISP core allows cross-organization unauthorized modification or deletion of analyst data, event reports, collections, templates, and decaying models
Summary
MISP core contained multiple broken access-control flaws where authorization checks were performed against the wrong entity, or where ownership/editability checks were missing on write paths. In affected subsystems, a lower-privileged authenticated user with the relevant feature permission could cause the application to authorize one object but mutate another, or could modify objects that were merely visible rather than editable by the user’s organization.
The affected paths included:
* Event Reports tag removal: the route-authorized report could differ from the report ID used for tag detachment, enabling cross-organization tag removal from another event report
* Collection Elements bulk deletion: bulk deletion authorized against a collection whose ID matched the collection-element row ID, rather than the element’s actual parent collection, enabling deletion of elements from collections the user did not own.
* Analyst Data capture/update: nested analyst data updates could overwrite an existing record without applying the normal canEditAnalystData ownership check, enabling cross-organization overwrite of analyst data records.
* Template Elements editing: editing authorized against a template whose ID matched the template-element ID, rather than the element’s actual parent template, enabling unauthorized edits to another organization’s template elements.
* Decaying Model editing and mappings: write paths loaded models using view-scope access but did not verify edit ownership, enabling users to edit or remap visible models owned by another organization.
Successful exploitation could allow an authenticated user with subsystem-specific permissions to perform unauthorized cross-organization modifications or deletions of MISP data, resulting in integrity loss, unauthorized tampering with shared intelligence, and disruption of analyst workflows.
Severity
CWE
Assigner
References
5 references
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "misp",
"repo": "https://github.com/misp/misp",
"vendor": "misp",
"versions": [
{
"lessThanOrEqual": "2.5.41",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "Andras Iklody"
},
{
"lang": "en",
"type": "analyst",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "tool",
"value": "Claude (the international export version)"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eMISP core contained multiple broken access-control flaws where authorization checks were performed against the wrong entity, or where ownership/editability checks were missing on write paths. In affected subsystems, a lower-privileged authenticated user with the relevant feature permission could cause the application to authorize one object but mutate another, or could modify objects that were merely visible rather than editable by the user\u2019s organization.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eThe affected paths included:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cstrong\u003eEvent Reports tag removal\u003c/strong\u003e: the route-authorized report could differ from the report ID used for tag detachment, enabling cross-organization tag removal from another event report\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eCollection Elements bulk deletion\u003c/strong\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e: bulk deletion authorized against a collection whose ID matched the collection-element row ID, rather than the element\u2019s actual parent collection, enabling deletion of elements from collections the user did not own.\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u003cstrong\u003eAnalyst Data capture/update\u003c/strong\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e: nested analyst data updates could overwrite an existing record without applying the normal \u003c/span\u003e\u003ccode\u003ecanEditAnalystData\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;ownership check, enabling cross-organization overwrite of analyst data records.\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u003cstrong\u003eTemplate Elements editing\u003c/strong\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e: editing authorized against a template whose ID matched the template-element ID, rather than the element\u2019s actual parent template, enabling unauthorized edits to another organization\u2019s template elements.\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u003cstrong\u003eDecaying Model editing and mappings\u003c/strong\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e: write paths loaded models using view-scope access but did not verify edit ownership, enabling users to edit or remap visible models owned by another organization.\u0026nbsp;\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e\u003c/ul\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eSuccessful exploitation could allow an authenticated user with subsystem-specific permissions to perform unauthorized cross-organization modifications or deletions of MISP data, resulting in integrity loss, unauthorized tampering with shared intelligence, and disruption of analyst workflows.\u003c/span\u003e\u003cbr\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u003cbr\u003e\u003c/span\u003e"
}
],
"value": "MISP core contained multiple broken access-control flaws where authorization checks were performed against the wrong entity, or where ownership/editability checks were missing on write paths. In affected subsystems, a lower-privileged authenticated user with the relevant feature permission could cause the application to authorize one object but mutate another, or could modify objects that were merely visible rather than editable by the user\u2019s organization.\n\n\nThe affected paths included:\n\n * Event Reports tag removal: the route-authorized report could differ from the report ID used for tag detachment, enabling cross-organization tag removal from another event report\n\n\n\n\n * Collection Elements bulk deletion: bulk deletion authorized against a collection whose ID matched the collection-element row ID, rather than the element\u2019s actual parent collection, enabling deletion of elements from collections the user did not own.\n * Analyst Data capture/update: nested analyst data updates could overwrite an existing record without applying the normal canEditAnalystData\u00a0ownership check, enabling cross-organization overwrite of analyst data records.\n * Template Elements editing: editing authorized against a template whose ID matched the template-element ID, rather than the element\u2019s actual parent template, enabling unauthorized edits to another organization\u2019s template elements.\n * Decaying Model editing and mappings: write paths loaded models using view-scope access but did not verify edit ownership, enabling users to edit or remap visible models owned by another organization.\u00a0\n\n\n\n\n\n\n\n\nSuccessful exploitation could allow an authenticated user with subsystem-specific permissions to perform unauthorized cross-organization modifications or deletions of MISP data, resulting in integrity loss, unauthorized tampering with shared intelligence, and disruption of analyst workflows."
}
],
"impacts": [
{
"capecId": "CAPEC-115",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-115 Authentication Bypass"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:L/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-639",
"description": "CWE-639 Authorization Bypass Through User-Controlled Key",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/24d7e91339a3ef043652dd5799c36e5065b2bb4a"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/57ad774d21bd1863d060a9e6e73ae54eb96784ce"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/3aecc04d5816189412b589cf590c6dbe9a8db5c0"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/ba2f51fe7440ba2c6043ccde858cac1e25f96931"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/744005cefdc3b943bd29669c3b34cc66a5fc2154"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Broken access control in MISP core allows cross-organization unauthorized modification or deletion of analyst data, event reports, collections, templates, and decaying models",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20099"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-56424",
"datePublished": "2026-06-22T12:13:00.000Z",
"dateReserved": "2026-06-22T12:17:10.186Z",
"dateUpdated": "2026-06-22T12:17:10.271177Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20099"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GCVE-1-2026-20094 (CVE-2026-56423)
Vulnerability from gna-1 – Published: 2026-06-22 11:54 – Updated: 2026-06-22 11:56
VLAI
EPSS
VEX
Title
MISP Core: Broken access control allows instance-wide unauthorized deletion of event reports and sharing groups via bulk deletion endpoints
Summary
MISP Core contained broken access-control checks in the bulk deletion flows for Event Reports and Sharing Groups. The affected deleteSelection handlers authorized deletion using broad role-level permissions instead of validating authorization for each selected object.
For Event Reports, EventReportsController::deleteSelection relied on the global perm_add capability rather than a per-report ownership/authorization check. As a result, a contributor-level user could submit report IDs or UUIDs for reports belonging to other organisations and hard-delete them instance-wide. The fix changed the callback to call EventReport::fetchIfAuthorized($user, $itemId, 'delete') for each selected report before deletion.
For Sharing Groups, SharingGroupsController::deleteSelection relied on the global perm_sharing_group capability rather than verifying ownership of each selected sharing group. This allowed a sharing-group-capable user to hard-delete sharing groups owned by other organisations, bypassing the per-object ownership gate used by the single-object delete action. The fix changed the callback to call SharingGroup::checkIfOwner($user, $itemId) for each selected sharing group.
An authenticated attacker with the relevant broad role permission could abuse the affected bulk deletion endpoints to delete objects outside their organisation’s authorization scope, causing loss of event-report content or sharing-group configuration across the instance.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
2 references
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "misp",
"repo": "https://github.com/MISP/misp",
"vendor": "misp",
"versions": [
{
"lessThanOrEqual": "2.5.41",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "Andras Iklody"
},
{
"lang": "en",
"type": "analyst",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "tool",
"value": "Claude (the international export version)"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eMISP Core contained broken access-control checks in the bulk deletion flows for \u003cstrong\u003eEvent Reports\u003c/strong\u003e\u0026nbsp;and \u003cstrong\u003eSharing Groups\u003c/strong\u003e. The affected \u003ccode\u003edeleteSelection\u003c/code\u003e\u0026nbsp;handlers authorized deletion using broad role-level permissions instead of validating authorization for each selected object.\u003c/p\u003e\u003cp\u003eFor \u003cstrong\u003eEvent Reports\u003c/strong\u003e, \u003ccode\u003eEventReportsController::deleteSelection\u003c/code\u003e\u0026nbsp;relied on the global \u003ccode\u003eperm_add\u003c/code\u003e\u0026nbsp;capability rather than a per-report ownership/authorization check. As a result, a contributor-level user could submit report IDs or UUIDs for reports belonging to other organisations and hard-delete them instance-wide. The fix changed the callback to call \u003ccode\u003eEventReport::fetchIfAuthorized($user, $itemId, \u0027delete\u0027)\u003c/code\u003e\u0026nbsp;for each selected report before deletion.\u003c/p\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eFor \u003c/span\u003e\u003cstrong\u003eSharing Groups\u003c/strong\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, \u003c/span\u003e\u003ccode\u003eSharingGroupsController::deleteSelection\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;relied on the global \u003c/span\u003e\u003ccode\u003eperm_sharing_group\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;capability rather than verifying ownership of each selected sharing group. This allowed a sharing-group-capable user to hard-delete sharing groups owned by other organisations, bypassing the per-object ownership gate used by the single-object delete action. The fix changed the callback to call \u003c/span\u003e\u003ccode\u003eSharingGroup::checkIfOwner($user, $itemId)\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;for each selected sharing group.\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003cp\u003eAn authenticated attacker with the relevant broad role permission could abuse the affected bulk deletion endpoints to delete objects outside their organisation\u2019s authorization scope, causing loss of event-report content or sharing-group configuration across the instance.\u003c/p\u003e\u003cbr\u003e\u003cbr\u003e\u003c/div\u003e"
}
],
"value": "MISP Core contained broken access-control checks in the bulk deletion flows for Event Reports\u00a0and Sharing Groups. The affected deleteSelection\u00a0handlers authorized deletion using broad role-level permissions instead of validating authorization for each selected object.\n\nFor Event Reports, EventReportsController::deleteSelection\u00a0relied on the global perm_add\u00a0capability rather than a per-report ownership/authorization check. As a result, a contributor-level user could submit report IDs or UUIDs for reports belonging to other organisations and hard-delete them instance-wide. The fix changed the callback to call EventReport::fetchIfAuthorized($user, $itemId, \u0027delete\u0027)\u00a0for each selected report before deletion.\n\n\n\n\nFor Sharing Groups, SharingGroupsController::deleteSelection\u00a0relied on the global perm_sharing_group\u00a0capability rather than verifying ownership of each selected sharing group. This allowed a sharing-group-capable user to hard-delete sharing groups owned by other organisations, bypassing the per-object ownership gate used by the single-object delete action. The fix changed the callback to call SharingGroup::checkIfOwner($user, $itemId)\u00a0for each selected sharing group.\n\n\n\n\nAn authenticated attacker with the relevant broad role permission could abuse the affected bulk deletion endpoints to delete objects outside their organisation\u2019s authorization scope, causing loss of event-report content or sharing-group configuration across the instance."
}
],
"impacts": [
{
"capecId": "CAPEC-115",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-115 Authentication Bypass"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/ada02fa6d7558732aa4712fd5e9451cd8c5b7a64"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/f99b3f16ef22c7acf10e17036c777759cf031c15"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "MISP Core: Broken access control allows instance-wide unauthorized deletion of event reports and sharing groups via bulk deletion endpoints",
"x_gcve": [
{
"recordType": "advisory",
"vulnId": "gcve-1-2026-20094"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2026-56423",
"datePublished": "2026-06-22T11:54:10.298853Z",
"dateReserved": "2026-06-22T11:56:07.846Z",
"dateUpdated": "2026-06-22T11:56:08.008149Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED",
"vulnId": "gcve-1-2026-20094"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
Mitigation
Architecture and Design
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Architecture and Design
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration
Installation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.