GCVE-1-2026-20106 (CVE-2026-94394)

Vulnerability from gna-1 – Published: 2026-09-21 13:25 – Updated: 2026-09-21 13:25
VLAI
Title
MISP ObjectReferencesController: Granular Distribution and Sharing Group Restrictions Bypassed When Adding Object References
Summary
When a regular user adds a reference between objects or attributes, MISP checks whether the user can access the overall event, but it does not always check whether the individual pieces of data are also allowed for that user. Because of this, someone who can view an event could potentially access attributes or objects inside that event that were meant to be restricted to a specific sharing group or distribution level. The vulnerability affects authenticated users who are not site administrators and who already have access to an event containing more restricted data. The main impact is that users may be able to view sensitive attribute values, object details, or related object data that they should not normally be allowed to see.
CWE
Assigner
GNA-1 This instance
References
Impacted products
Vendor Product Version CPE status
MISP MISP Affected: 0 , < 2.5.47 (semver)
guessed Create a notification for this product.
GCVE extensions
AI involvement GCVE-BCP-05-X-01
Whole record AI-generated Review: review GNA-1

Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.

ai-computer-assisted:llm-generatedai-computer-assisted:classification
Model Source Identifier
qwen3.8:27b ollama qwen3.8:27b
Patch provenance GCVE-BCP-05-X-02
Generator
patch2vuln.py on 2026-09-21 13:15
Model
qwen3.8:27b
Input
https://github.com/MISP/MISP/commit/f36634e57.patch 2688fca1334e…
Confidence
medium
Commit Subject Patch SHA-256
f36634e57b93 fix: [security] Extended event granular restrictions ignored 2688fca1334e…
Fix summary

The fix introduces granular authorization checks in the ObjectReferencesController add() method. For non-site-admin users, the query conditions for attributes, objects, and object attributes are now augmented with OR clauses that restrict results to: (1) entities belonging to the user's own event, (2) entities with unrestricted distribution levels (1, 2, 3, 5), or (3) entities with distribution level 4 whose sharing_group_id is in the user's authorized sharing group list. This ensures that only data the user is explicitly authorized to see under MISP's distribution and sharing-group model is included in the object reference operation.

Patch summary

In app/Controller/ObjectReferencesController.php, the add() method is modified to build dynamic condition arrays ($attributeConditions, $objectConditions, $objectAttributeConditions) that incorporate the current user's role and authorized sharing group IDs. For non-site-admin users, each condition array gains an OR clause filtering by event ownership, distribution levels (1,2,3,5), or distribution level 4 with a matching sharing_group_id from the user's authorized IDs. These condition arrays replace the previously hardcoded minimal conditions (deleted=0, object_id=0) in the Contain clauses for Attribute, Object, and nested Object.Attribute queries. The user's authorized sharing group IDs are obtained via SharingGroup->authorizedIds($user).

CVSS rationale

AV:N: MISP is a network-accessible web application. AC:L: The attack requires no special conditions beyond having a valid account with event-level access; no race conditions or complex setup needed. AT:N: No manipulation of a separate attack target is required. PR:L: The attacker needs a low-privilege authenticated account (any non-site-admin user with access to an event containing restricted attributes/objects). UI:N: No victim interaction is required; the attacker simply calls the API endpoint. VC:N/VI:N/VA:N: The MISP server itself (the vulnerable component) is not compromised in its own confidentiality, integrity, or availability. SC:H: The resource impact is high because restricted attribute values, object metadata, and object-attribute data that are explicitly gated by distribution levels and sharing groups are exposed to an unauthorized user. SI:N: No integrity impact on the data. SA:N: No safety impact.

Weakness rationale
  • CWE-862 The ObjectReferencesController add() method was missing authorization checks for granular distribution-level and sharing-group restrictions on attributes, objects, and object attributes. Only event-level access was verified, while the sub-entity level access controls (distribution levels 1-5, sharing group membership) were entirely absent from the query conditions. This is a classic missing authorization check at a finer granularity than what was enforced.
Attack pattern rationale
  • CAPEC-109 The closest plausible CAPEC is Parameter Tampering. An authenticated user supplies an objectId parameter to the add() endpoint, and the application fails to enforce proper authorization on the sub-entities (attributes, objects, object attributes) associated with that object. The user effectively 'tampers' with the scope of accessible data by leveraging event-level access to reach restricted sub-entities. This is not a perfect match because the user is not modifying a parameter to an invalid value but rather exploiting the absence of a check on a valid parameter's sub-resources. No CAPEC specifically models 'broken granular access control' or 'insecure direct object reference at sub-entity level,' making CAPEC-109 the best available approximation.
Assumptions to verify
  • The exact affected and fixed version numbers are not specified in the patch metadata. The tag_version_boundary indicates the fix commit is 140 commits after v2.5.47, but the precise release version containing the fix is unknown.
  • The CAPEC-109 (Parameter Tampering) mapping is the closest available match but is not a perfect fit; the vulnerability is more precisely a missing granular authorization check rather than parameter manipulation. No CAPEC specifically models broken sub-entity access control.
  • The CVSS SC:H rating assumes that the exposed attribute/object data constitutes sensitive information (e.g., IOCs, malware indicators, threat intelligence) whose unauthorized disclosure is a significant confidentiality impact. If the data is considered low-sensitivity, SC:L may be more appropriate.
  • The vulnerability requires the attacker to already have event-level access; it does not grant access to events the user cannot see. The bypass is limited to granular restrictions within an already-accessible event.
  • The patch only addresses the add() method in ObjectReferencesController; other methods or controllers with similar patterns may or may not be affected, but no evidence of additional affected code paths is present in this patch.
Model comparison

Selected qwen3.8:27b by deterministic-consensus-v1
The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required.

Model Score Agreement Confidence Assumptions
qwen3.8:27b 5 9 medium 5

{
  "containers": {
    "cna": {
      "affected": [
        {
          "modules": [
            "ObjectReferencesController"
          ],
          "product": "MISP",
          "programFiles": [
            "app/Controller/ObjectReferencesController.php"
          ],
          "repo": "https://github.com/MISP/MISP",
          "vendor": "MISP",
          "versions": [
            {
              "lessThan": "2.5.47",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Jeroen Pinoy"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "iglocska"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "When a regular user adds a reference between objects or attributes, MISP checks whether the user can access the overall event, but it does not always check whether the individual pieces of data are also allowed for that user.\u003cbr\u003e\u003cbr\u003e\u003cp\u003eBecause of this, someone who can view an event could potentially access attributes or objects inside that event that were meant to be restricted to a specific sharing group or distribution level.\u003c/p\u003eThe vulnerability affects authenticated users who are not site administrators and who already have access to an event containing more restricted data.\u003cbr\u003e\u003cbr\u003eThe main impact is that users may be able to view sensitive attribute values, object details, or related object data that they should not normally be allowed to see.\u003cbr\u003e"
            }
          ],
          "value": "When a regular user adds a reference between objects or attributes, MISP checks whether the user can access the overall event, but it does not always check whether the individual pieces of data are also allowed for that user.\n\nBecause of this, someone who can view an event could potentially access attributes or objects inside that event that were meant to be restricted to a specific sharing group or distribution level.\n\nThe vulnerability affects authenticated users who are not site administrators and who already have access to an event containing more restricted data.\n\nThe main impact is that users may be able to view sensitive attribute values, object details, or related object data that they should not normally be allowed to see."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-109",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-109 Parameter Tampering"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "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:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "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": [
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/MISP/MISP/commit/f36634e57"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe fix introduces granular authorization checks in the ObjectReferencesController add() method. For non-site-admin users, the query conditions for attributes, objects, and object attributes are now augmented with OR clauses that restrict results to: (1) entities belonging to the user\u0027s own event, (2) entities with unrestricted distribution levels (1, 2, 3, 5), or (3) entities with distribution level 4 whose sharing_group_id is in the user\u0027s authorized sharing group list. This ensures that only data the user is explicitly authorized to see under MISP\u0027s distribution and sharing-group model is included in the object reference operation.\u003c/p\u003e"
            }
          ],
          "value": "The fix introduces granular authorization checks in the ObjectReferencesController add() method. For non-site-admin users, the query conditions for attributes, objects, and object attributes are now augmented with OR clauses that restrict results to: (1) entities belonging to the user\u0027s own event, (2) entities with unrestricted distribution levels (1, 2, 3, 5), or (3) entities with distribution level 4 whose sharing_group_id is in the user\u0027s authorized sharing group list. This ensures that only data the user is explicitly authorized to see under MISP\u0027s distribution and sharing-group model is included in the object reference operation."
        }
      ],
      "title": "MISP ObjectReferencesController: Granular Distribution and Sharing Group Restrictions Bypassed When Adding Object References",
      "x_gcve": [
        {
          "extensions": {
            "bcp-05-x-01": {
              "ai_annotations": [
                {
                  "ai_level": "generated",
                  "description": "Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.",
                  "gna_source": 1,
                  "models": [
                    {
                      "gna_source": 1,
                      "identifier": "qwen3.8:27b",
                      "name": "qwen3.8:27b",
                      "source": "ollama"
                    }
                  ],
                  "review_status": "review",
                  "scope": "record",
                  "tags": [
                    "ai-computer-assisted:llm-generated",
                    "ai-computer-assisted:classification"
                  ]
                }
              ]
            },
            "bcp-05-x-02": {
              "x_patch2vuln": {
                "assumptions": [
                  "The exact affected and fixed version numbers are not specified in the patch metadata. The tag_version_boundary indicates the fix commit is 140 commits after v2.5.47, but the precise release version containing the fix is unknown.",
                  "The CAPEC-109 (Parameter Tampering) mapping is the closest available match but is not a perfect fit; the vulnerability is more precisely a missing granular authorization check rather than parameter manipulation. No CAPEC specifically models broken sub-entity access control.",
                  "The CVSS SC:H rating assumes that the exposed attribute/object data constitutes sensitive information (e.g., IOCs, malware indicators, threat intelligence) whose unauthorized disclosure is a significant confidentiality impact. If the data is considered low-sensitivity, SC:L may be more appropriate.",
                  "The vulnerability requires the attacker to already have event-level access; it does not grant access to events the user cannot see. The bypass is limited to granular restrictions within an already-accessible event.",
                  "The patch only addresses the add() method in ObjectReferencesController; other methods or controllers with similar patterns may or may not be affected, but no evidence of additional affected code paths is present in this patch."
                ],
                "capecRationale": [
                  {
                    "capecId": "CAPEC-109",
                    "rationale": "The closest plausible CAPEC is Parameter Tampering. An authenticated user supplies an objectId parameter to the add() endpoint, and the application fails to enforce proper authorization on the sub-entities (attributes, objects, object attributes) associated with that object. The user effectively \u0027tampers\u0027 with the scope of accessible data by leveraging event-level access to reach restricted sub-entities. This is not a perfect match because the user is not modifying a parameter to an invalid value but rather exploiting the absence of a check on a valid parameter\u0027s sub-resources. No CAPEC specifically models \u0027broken granular access control\u0027 or \u0027insecure direct object reference at sub-entity level,\u0027 making CAPEC-109 the best available approximation."
                  }
                ],
                "commit": "f36634e57b93ad9daa3ab9530b76b9e5cba796e2",
                "confidence": "medium",
                "credits": [
                  {
                    "lang": "en",
                    "type": "reporter",
                    "value": "Jeroen Pinoy"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "iglocska"
                  }
                ],
                "cvssRationale": "AV:N: MISP is a network-accessible web application. AC:L: The attack requires no special conditions beyond having a valid account with event-level access; no race conditions or complex setup needed. AT:N: No manipulation of a separate attack target is required. PR:L: The attacker needs a low-privilege authenticated account (any non-site-admin user with access to an event containing restricted attributes/objects). UI:N: No victim interaction is required; the attacker simply calls the API endpoint. VC:N/VI:N/VA:N: The MISP server itself (the vulnerable component) is not compromised in its own confidentiality, integrity, or availability. SC:H: The resource impact is high because restricted attribute values, object metadata, and object-attribute data that are explicitly gated by distribution levels and sharing groups are exposed to an unauthorized user. SI:N: No integrity impact on the data. SA:N: No safety impact.",
                "fixSummary": "The fix introduces granular authorization checks in the ObjectReferencesController add() method. For non-site-admin users, the query conditions for attributes, objects, and object attributes are now augmented with OR clauses that restrict results to: (1) entities belonging to the user\u0027s own event, (2) entities with unrestricted distribution levels (1, 2, 3, 5), or (3) entities with distribution level 4 whose sharing_group_id is in the user\u0027s authorized sharing group list. This ensures that only data the user is explicitly authorized to see under MISP\u0027s distribution and sharing-group model is included in the object reference operation.",
                "generatedAt": "2026-09-21T13:15:28.001598Z",
                "generator": "patch2vuln.py",
                "model": "qwen3.8:27b",
                "modelComparison": {
                  "rankings": [
                    {
                      "agreementScore": 9,
                      "assumptionCount": 5,
                      "confidence": "medium",
                      "model": "qwen3.8:27b",
                      "score": 5
                    }
                  ],
                  "selectedModel": "qwen3.8:27b",
                  "selectionMethod": "deterministic-consensus-v1",
                  "selectionNotice": "The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required."
                },
                "patchSha256": "2688fca1334e3016b8b885ce926749f8d47e49d7b657cf38f7b2edcd6eaf6cf0",
                "patchSummary": "In app/Controller/ObjectReferencesController.php, the add() method is modified to build dynamic condition arrays ($attributeConditions, $objectConditions, $objectAttributeConditions) that incorporate the current user\u0027s role and authorized sharing group IDs. For non-site-admin users, each condition array gains an OR clause filtering by event ownership, distribution levels (1,2,3,5), or distribution level 4 with a matching sharing_group_id from the user\u0027s authorized IDs. These condition arrays replace the previously hardcoded minimal conditions (deleted=0, object_id=0) in the Contain clauses for Attribute, Object, and nested Object.Attribute queries. The user\u0027s authorized sharing group IDs are obtained via SharingGroup-\u003eauthorizedIds($user).",
                "patchTruncated": false,
                "patches": [
                  {
                    "commit": "f36634e57b93ad9daa3ab9530b76b9e5cba796e2",
                    "patchSha256": "2688fca1334e3016b8b885ce926749f8d47e49d7b657cf38f7b2edcd6eaf6cf0",
                    "source": "https://github.com/MISP/MISP/commit/f36634e57.patch",
                    "sourceUrl": "https://github.com/MISP/MISP/commit/f36634e57.patch",
                    "subject": "fix: [security] Extended event granular restrictions ignored"
                  }
                ],
                "source": "https://github.com/MISP/MISP/commit/f36634e57.patch",
                "subject": "fix: [security] Extended event granular restrictions ignored",
                "tagVersionBoundary": {
                  "commits_after_fix": 140,
                  "repository": "https://github.com/MISP/MISP",
                  "tag": "v2.5.47",
                  "version": "2.5.47",
                  "version_type": "semver"
                },
                "weaknessRationale": [
                  {
                    "cweId": "CWE-862",
                    "rationale": "The ObjectReferencesController add() method was missing authorization checks for granular distribution-level and sharing-group restrictions on attributes, objects, and object attributes. Only event-level access was verified, while the sub-entity level access controls (distribution levels 1-5, sharing group membership) were entirely absent from the query conditions. This is a classic missing authorization check at a finer granularity than what was enforced."
                  }
                ]
              }
            }
          },
          "recordType": "advisory",
          "vulnId": "GCVE-1-2026-20106"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "00000000-0000-4000-9000-000000000000",
    "cveId": "CVE-2026-94394",
    "datePublished": "2026-09-21T13:25:31.534037Z",
    "dateReserved": "2026-09-21T13:25:38.483Z",
    "dateUpdated": "2026-09-21T13:25:38.557803Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1-2026-20106"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…