We've been running ThreatConnect for several years, and our instance relies heavily on custom attributes across groups and indicators to encode internal workflow states and enrichment data. Following our upgrade to the latest major version this weekend, approximately half of these custom attributes are no longer visible in the UI or accessible via the API. The attributes themselves still appear to exist in the database schema, but they are not populated or retrievable for existing objects.
Our initial investigation suggests the issue is isolated to attributes created via the older v2 API, whereas attributes created through the v3 API remain intact. A query to the `/api/v2/types/attributeTypes` endpoint still lists the "missing" attributes, but they are absent from any specific indicator or group's attribute list. This has broken numerous automated playbooks and internal dashboards.
Has anyone else encountered a similar regression after a major version upgrade? Specifically, the loss of custom attribute data linked to pre-v3 API entities? We are currently auditing our API migration history, but the discontinuity appears severe. We are considering a rollback, but I'm looking for confirmation that this is a known issue or if there are documented steps to remap or restore these attribute bindings. Any insight into the upgrade path's handling of legacy custom attribute definitions would be appreciated.
null
Ouch, that sounds like a brutal upgrade side effect. We haven't used ThreatConnect, but we saw a similar pattern after a major Elasticsearch version jump where old, custom field mappings got dropped silently. The schema existed, but the data was treated as if it weren't there.
Your v2 vs. v3 API clue feels key. I'd bet the upgrade process didn't migrate the attribute bindings for legacy objects, only the type definitions. Before you rollback, check if there's a data migration script they might have shipped separately. Sometimes those are optional and easy to miss.
Any chance you can run a test on a single indicator to see if you can *re-add* one of the missing attributes via v3 and have it pick up the old value from the db? Might help confirm it's a linkage issue.
cost first, then scale
Great point about the v2/v3 split being the key. We ran into something similar with a B2B platform's upgrade where old user metadata got orphaned.
The test you suggested is smart. If re-adding via v3 works, it at least confirms the data's still there, just detached. That gives you a path forward, even if it's a manual one.
Sometimes the migration script is tucked away in the release notes or a separate "post-upgrade tasks" doc. Hope you find it!
Happy customers, happy life.