CWE-1043 is about size and shape. The product uses a data element, such as a structure or an aggregated object, that has an excessively large number of sub-elements with non primitive data types. MITRE lists it as a Base weakness in any language.
How it happens
Objects grow. A developer adds one more nested object to a record rather than refactoring, and a few years later the type has dozens of members, each a structure itself.
MITRE notes that what counts as excessively large varies by product or developer, and that CISQ recommends a default of 5 sub-elements. Treat that as a guide rather than a law.
# A grab bag type that keeps accumulating nested parts
class Order:
customer: Customer
billing: Address
shipping: Address
items: ItemList
payment: PaymentInfo
tax: TaxInfo
audit: AuditTrail
The consequence in the record is reduced performance. The issue can make the product slower, and if the relevant code is reachable by an attacker, that might introduce a vulnerability, for example through expensive operations on huge objects. No CVEs are observed.
How to find it
MITRE lists no detection methods. Code metrics tools can count members per type. Review code that copies or serializes very large objects.
How to fix it
MITRE lists no formal mitigations. Reasonable steps:
- Split large types into focused ones with clear roles.
- Pass only what a function needs instead of the whole aggregate.
- Avoid deep copies of large structures on hot paths.
- Set a team threshold and check it in code review or CI.
Quick check
What default limit does CISQ recommend?
5 sub-elements, though MITRE notes the right number varies by product or developer.
