CWE-842, Placement of User into Incorrect Group, is a simple idea with ugly results. Either the product or an administrator puts a user into the wrong group. If that group has more rights than the user should have, the user can reach resources and actions that policy never meant to give them.
It hits anything that uses groups or roles to decide access: operating systems, content management systems, admin consoles, internal tools, SaaS back ends.
How it happens
MITRE describes two sources. The product itself assigns the group, or a person does. The product-side causes in the observed examples are worth reading closely:
- An operating system assigned a user to a privileged group, which led to root access (CVE-1999-1193, details here).
- A crafted web request allowed the creation of users with arbitrary group membership (CVE-2010-3716).
- Improper processing of configuration options left users with unintended group memberships (CVE-2008-5397).
- A CMS let remote administrators promote other users to the administrator group, against its own security model (CVE-2007-6644).
The common thread is that group membership is treated as a fact the system can trust, while the code that sets it accepts input it should not.
What an attacker gains
MITRE lists one consequence: access control, specifically gaining privileges or assuming another identity. There is a second sting. The access control system may not detect malicious use of the group, because from its point of view the user simply belongs there.
How to find it
The MITRE record lists no detection methods for this weakness, so this comes down to review:
- List every code path that writes a group or role: signup, invite, import, SSO mapping, admin screens, config files.
- Check which of those paths read a group name from a request body or config value.
- Audit current membership of privileged groups against a known list of who should be in them.
How to fix it
The MITRE entry gives no formal mitigations. These are practical steps that follow from the causes above:
- Assign groups on the server only. Never accept a group or role field from the client during signup or profile update.
- Make the default group the least privileged one.
- Require an authorization check before anyone can change membership of a privileged group, and log every change.
- Review privileged group membership on a schedule and remove what nobody can justify.
Quick check
A signup form posts a field named group. Is that a problem?
Yes, if the server uses it to set membership. That is the pattern behind the arbitrary group creation example. Set the group server side and ignore the field.
Can an administrator cause this weakness?
Yes. MITRE says either the product or the administrator places the user into the incorrect group.
