Question: update custom fields of existing vulnerabilities

[simona-ber]

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.

[chisholm]

Interesting. I don't know why custom_properties was 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:

Vulnerability(x_opencti_cisa_kev=False, custom_properties={"x_opencti_cisa_kev": True}, allow_custom=True)

so that x_opencti_cisa_kev is 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 the x_opencti_cisa_key property. This happens here:

cti-python-stix2/stix2/versioning.py

Line 280 in 6dd83fa

return cls(**{k: v for k, v in new_obj_inner.items() if v is not None})

new_obj_inner includes the existing vulnerability property values, updated with the kwargs you passed into new_version(). That means it has both the old property value and the custom_properties arg, 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 calling new_version() with that funny way of setting custom properties. Just set the new property values directly as kwargs:

stix2.new_version(vuln_obj, x_opencti_cisa_kev=True, allow_custom=True)

It should work better.