Repository navigation
Question: update custom fields of existing vulnerabilities #639
Description
Hello,
I have the following JSON bundle. The vulnerability has been created with allow_custom = True:
{
"type": "bundle",
"id": "bundle--b880c614-3094-4f0b-ace3-abe21fd4446b",
"objects": [
{
"type": "vulnerability",
"spec_version": "2.1",
"id": "vulnerability--cb09aedd-5895-59dc-8d61-af0b27771411",
"created": "2025-04-17T15:34:10.384365Z",
"modified": "2025-04-17T15:34:10.384365Z",
"name": "EUVD-2025-32433",
"description": "Erlang/OTP is a set of libraries for the Erlang programming language. Prior to versions OTP-27.3.3, OTP-26.2.5.11, and OTP-25.3.2.20, a SSH server may allow an attacker to perform unauthenticated remote code execution (RCE). By exploiting a flaw in SSH protocol message handling, a malicious actor could gain unauthorized access to affected systems and execute arbitrary commands without valid credentials. This issue is patched in versions OTP-27.3.3, OTP-26.2.5.11, and OTP-25.3.2.20. A temporary workaround involves disabling the SSH server or to prevent access via firewall rules.",
"external_references": [
{
"source_name": "ENISA",
"url": "https://euvd.enisa.europa.eu/vulnerability/EUVD-2025-32433",
"external_id": "EUVD-2025-32433"
},
{
"source_name": "",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32433"
},
{
"source_name": "",
"url": "https://github.com/erlang/otp/releases/tag/OTP-27.3.3"
},
{
"source_name": "",
"url": "https://github.com/erlang/otp/security/advisories/GHSA-37cp-fgq5-7wc2"
},
{
"source_name": "",
"url": "https://www.openwall.com/lists/oss-security/2025/04/16/2"
}
]
"x_opencti_aliases": "CVE-2025-32433",
"x_opencti_cisa_kev": false,
"x_opencti_cvss_base_score": 10.0,
"x_opencti_epss_percentile": 0.87146,
"x_opencti_epss_score": 0.03624
},
{
"type": "software",
"spec_version": "2.1",
"id": "software--a2c10b9a-4024-54a1-b4ec-db675ffe254b",
"name": "Erlang/OTP"
},
{
"type": "relationship",
"spec_version": "2.1",
"id": "relationship--6b42c0f9-36c0-463f-a926-90241ab57199",
"created": "2025-06-10T09:07:53.052683Z",
"modified": "2025-06-10T09:07:53.052683Z",
"relationship_type": "has",
"source_ref": "software--a2c10b9a-4024-54a1-b4ec-db675ffe254b",
"target_ref": "vulnerability--cb09aedd-5895-59dc-8d61-af0b27771411"
}
]
}
I need to update this vulnerability by setting the x_opencti_cisa_kev custom field to True. So in my code I try to do something like this:
However, it seems that any change to the existing custom fields is simply not taken into consideration: in the resulting bundle the field is still set to False. I tried also with other custom fields and I get the same behavior, whereas if I try to change a standard field like the description the new_version function works.
Am I doing something wrong? If I create the vulnerability from scratch with the updated custom fields I have no issue.
Activity
[-]Update custom fields of existing vulnerabilities[/-][+]Question: update custom fields of existing vulnerabilities[/+]chisholm commentedon Jun 10, 2025
Interesting. I don't know why
custom_propertieswas added as a way to set custom properties. Setting them as plain keyword args like everything else seems like it would work just as well. Having two ways of doing something means there can be conflicts. E.g. you could have:so that
x_opencti_cisa_kevis set twice, to conflicting values. What happens in this case? The way the object initialization code is written, the kwarg will take priority. Maybe it should have been an error? Better yet, one could design the APIs to make such mistakes impossible.Anyway, the
new_version()function is constructing the new version of the vulnerability object as above, with conflicting definitions of thex_opencti_cisa_keyproperty. This happens here:cti-python-stix2/stix2/versioning.py
Line 280 in 6dd83fa
new_obj_innerincludes the existing vulnerability property values, updated with the kwargs you passed intonew_version(). That means it has both the old property value and thecustom_propertiesarg, with the conflicting value. The old value is taking priority over the new one.I'd say, don't use
custom_properties. I don't think we even thought of callingnew_version()with that funny way of setting custom properties. Just set the new property values directly as kwargs:It should work better.