CWE-573 is a class level weakness. It says: the product does not follow, or incorrectly follows, the specification required by a language, environment, framework, protocol or platform.
That sounds abstract, so here is the plain version. Every API has rules. Call this before that. Do not pass null. Do not reuse this object across threads. Do not call this method yourself, the container does. When a caller breaks the rules, behavior is undefined, and sometimes undefined behavior is exploitable.
MITRE puts it this way: when using external functionality, such as an API, it is important to call it in accordance with the requirements of that functionality, or unintended behaviors may result, possibly leaving the system vulnerable to a number of exploits.
It is not language specific, and it covers a lot of ground.
How it happens
The common causes are ordinary.
- Misread documentation. The developer assumed what a parameter means without checking the spec.
- Version drift. The API changed in a new release and the calling code still follows the old contract.
- Copy and paste. A snippet from a forum works in the demo and breaks a requirement that matters in production.
- Convenience over rules. The spec says "do not do X", X is easier, and nothing stops you.
A short, generic illustration in Python, using a hash comparison where the library documents a specific safe call:
# Misuse: documentation says to compare digests in constant time
import hmac, hashlib
def check(token, expected):
mac = hmac.new(KEY, token, hashlib.sha256).hexdigest()
return mac == expected # ordinary comparison, timing varies
# Following the documented usage
def check(token, expected):
mac = hmac.new(KEY, token, hashlib.sha256).hexdigest()
return hmac.compare_digest(mac, expected)
Both versions run. Only one follows the library's guidance. That gap between works and is correct is what this weakness is about.
The MITRE record lists two observed CVEs in this family: CVE-2006-7140 and CVE-2006-4339. Both describe a cryptographic implementation that removes padding when it should not, which allowed forged signatures. The details are on the Gold pages for CVE-2006-7140 and CVE-2006-4339. In both, a specification said how padding must be handled, and the implementation did not follow it.
What an attacker gains
MITRE lists the consequence as quality degradation that varies by context. That honest vagueness is the point. The impact depends entirely on which specification was broken.
- Break a crypto padding rule and signatures can be forged, as the observed CVEs show.
- Break a memory ownership rule and you may corrupt memory.
- Break a session or threading rule and you may leak data between users.
- Break a protocol sequencing rule and you may skip a security step.
So the right question is never "is CWE-573 dangerous". It is "what does this specific rule protect".
How to find it
MITRE lists automated static analysis as able to find some instances. Because this is a broad class, use several angles.
- Linters and analyzers with API misuse rules. Many language ecosystems ship checks for known misuse patterns, especially for crypto and concurrency.
- Compiler and runtime warnings. Treat deprecation warnings as signals that the contract has changed.
- Code review against the documentation. For security sensitive APIs, a reviewer should have the spec open.
- Tests that cover the rule, not just the happy path. If the spec says invalid input must be rejected, test that it is.
- Upgrade review. When you move to a new major version of a library, read the changelog for contract changes before merging.
How to fix it
The record lists no formal mitigation, so these steps come from the definition itself.
- Read the specification for any security relevant API before using it, and again when you upgrade.
- Prefer high level, hard to misuse APIs. Use the library's recommended entry point rather than assembling primitives yourself.
- Wrap risky calls once. Put correct usage in a single helper, test it, and have the rest of the code call the helper.
- Turn on strict warnings and treat deprecation and misuse findings as build failures for security sensitive modules.
- Pin and review dependency upgrades, since a changed contract in a new version can turn correct calling code into incorrect calling code.
The last point is where dependency visibility matters. If a library fixes a specification handling bug, you want to know your version is affected and whether your code reaches the affected function. Reachability analysis helps with that second question. For a quick inventory, the free scan at gold.safeguard.sh/scan runs in your browser with no login, keeps the file on your machine, and handles up to 100 dependencies.
Quick check
What does CWE-573 describe?
Code that does not follow, or incorrectly follows, the specification of an API, framework, protocol or platform it uses.
How severe is it?
It varies by context. MITRE lists quality degradation, and the observed CVEs show cases where broken padding rules allowed forged signatures.
What is the most reliable habit?
Read the spec for security relevant calls, and wrap correct usage in one tested helper so it is not reimplemented everywhere.
