CWE-672 is the use of a resource after it has expired, been released or been revoked. It is the umbrella over bugs like use after free, using a closed file descriptor, and acting on a session or credential that should no longer be valid. The record lists mobile as a platform alongside the language-neutral ones, and the weakness appears wherever resources have a lifetime.
How it happens
A resource is released, and something still holds a reference to it. The reference is used later. What happens next depends on what the released resource has become.
Memory. The block is freed and then reused for something else. The stale pointer now points at another object's data.
Handles. A file descriptor is closed, the number is reused for a different file, and the old code writes to the wrong one.
Tokens and sessions. A credential is revoked or has expired, but a code path keeps accepting it, for example because a cached check was never refreshed.
Objects in concurrent code. One thread releases an object while another still uses it.
/* Vulnerable: use after free */
char *name = malloc(32);
strcpy(name, input);
free(name);
printf("%s\n", name); /* reads memory that is no longer ours */
The record's example is CVE-2009-3547: a chain where a race condition (CWE-362) might allow a resource to be released before it is operated on, leading to a NULL dereference (CWE-476). The release happened at the wrong moment because nothing coordinated the two threads.
What an attacker gains
MITRE lists two consequences.
- Integrity and confidentiality. If a released resource is reused or reallocated, an attempt to use the original may reach sensitive data that belongs to a different user or entity. The attacker can read or modify application data.
- Availability. A released resource may not be in an expected state, and later access can cause errors that crash the program.
The first consequence is the more serious one for multi-user systems. Stale access across a reuse boundary can mean one customer's data landing in another's session.
How to find it
The record lists automated static analysis (SAST), which can find some instances by analyzing source or compiled code without running it. Add these checks.
- For each release call (free, close, delete, revoke, logout), find every later use of the same reference on every path.
- Look for references stored in structures that outlive the release.
- Review cleanup code in error paths, where double handling and ordering mistakes cluster.
- Test concurrency: release and use from different threads under load.
- Run tests under a memory checking tool that reports use after free.
- For tokens, test that logout, expiry and revocation actually stop access, including for cached results.
How to fix it
MITRE lists no formal mitigations on this entry. The practical steps follow from its description and neighbors.
- Clear the reference at the moment of release: set pointers to NULL, drop the handle from tables.
- Give each resource a single owner responsible for release.
- Use language features that manage lifetime, such as smart pointers, ownership rules or garbage collected references, where available.
- Coordinate release with use through proper locking, as in improper locking.
- Make expiry checks happen at each use, not once at setup.
- Keep revoked credential lists current and consult them on every request.
/* Safer: drop the reference at release */
free(name);
name = NULL;
if (name) printf("%s\n", name);
A NULL check turns a silent memory bug into a handled case, though the better fix is to avoid using the reference at all.
Quick check
Why can use after release leak another user's data?
Released resources are often reused. A stale reference then points at the new owner's data, which is why MITRE lists reading application data as a consequence.
Does this only apply to memory?
No. It also covers handles, sessions, tokens and any resource that can expire, be released or be revoked.
What is the simplest habit that helps?
Clear or drop every reference to a resource at the moment it is released.
