Topic starter
23/06/2026 8:32 pm
TL;DR: Unosecur says Chegg’s April 2018 breach exposed data for more than 40 million users after a former contractor retained AWS root credentials without MFA, letting attackers exfiltrate S3-stored records and highlighting how weak identity hygiene turns cloud access into breach scale. Shared root access still defeats governance when lifecycle controls and monitoring are thin.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Chegg Data Breach and the need for granular identity hygiene”.
By the numbers:
- More than 40 million users were affected by the breach, according to Unosecur.
Key questions
Q: What breaks when a former contractor still has AWS root access?
A: The entire offboarding model breaks, because the access relationship outlives the business relationship.
Q: Why does missing MFA on a cloud root account create such a high risk?
A: Missing MFA weakens the last line of defense on the most privileged account in the environment.
Q: How can security teams know whether S3 access is crossing into exfiltration?
A: Look for unexpected bucket enumeration, spikes in object retrieval, and access patterns that do not match normal business activity.
Practitioner guidance
- Enforce root-account offboarding controls Inventory every cloud root or equivalent superuser account, assign named ownership, and require removal or replacement when staff or contractors leave a role.
- Require MFA on all privileged cloud identities Make multi-factor authentication mandatory for any administrative identity that can reach storage, billing, or security settings.
- Reduce the blast radius of storage permissions Separate read, list, and admin permissions for object storage, and remove broad access from identities that do not need it.
Bottom line: Chegg’s breach shows how retained cloud root access can turn a lifecycle failure into a large-scale data exposure event.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- The specific AWS access path Chegg allowed to remain active and how that created the breach window.
- The FTC remediation requirements tied to MFA, threat monitoring, encryption, and data access rights.
- The article's operational guidance on detecting bucket enumeration and exfiltration activity in cloud logs.
- The vendor's incident narrative on how monitoring and response could have reduced dwell time.
👉 Read Unosecur's analysis of the Chegg AWS root credential breach →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:37 am
Root access offboarding failed as a lifecycle control, not as a password problem: The former contractor’s access should have been ended when the business relationship changed, but the account remained usable. That is a governance failure in entitlement removal and exception handling, not a simple credential weakness. The implication is that cloud root accounts need a stricter joiner-mover-leaver model than ordinary administrative users.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should IAM teams do when every cloud account can become privileged?
A: They should treat privilege as a design attribute of the cloud estate, not a role label. That means identifying which accounts, services, and keys can reach production systems, then reducing rights until each identity only has the access needed for its workload. The goal is narrow, explicit scope.
👉 Read our full editorial: Chegg breach shows why granular identity hygiene still fails