An exposed facial image database is not a “privacy story” alone—it is a cloud configuration, retention, and third-party risk failure that security and GRC teams can learn from immediately. In August 2026, reporting on ClarityCheck described roughly nine million face-related image files found in cloud storage without password protection, totaling about 450 GB—coverage summarized by PetaPixel and investigated in detail by researcher Jeremiah Fowler via ExpressVPN.
Faces are hard (or impossible) to rotate like a password. When uploads, screenshots, and profile photos sit in poorly governed object storage, the blast radius includes identity fraud, unwanted AI training scrapes, and lasting privacy harm—especially when images of minors may be present.
This guide covers:
- What the exposure reportedly involved—and why “unindexed URL” is not a control
- A forensic section: artifacts, timeline questions, and evidence you should preserve
- A practical checklist to hunt similar gaps in your AWS/Azure/GCP estate
- How retention, vendor risk, and continuous cloud checks map to SecureSlate workflows
GIF via GIPHY
Related guides:
- 21 AWS cloud security strategies
- Cloud incident response
- ISO 27001 data retention policy
- Vendor risk assessment
- SecureSlate AWS integration
Key takeaways
- Biometric images are durable risk—once exposed, people cannot “reset” their face the way they reset a credential.
- Security through obscurity fails—an unindexed object URL discovered in public site code is still an access path.
- Retention claims need technical proof—stated deletion windows should match lifecycle rules, job logs, and sample inventories.
- Forensics starts before legal letters—preserve bucket configs, IAM, access logs, and disclosure timestamps early.
- SecureSlate ties posture to program—cloud misconfiguration findings, policies, vendor risk, and incident evidence in one audit-ready workflow.
What happened (and why it matters)
According to public reporting, ClarityCheck—a people-search / reverse-image lookup service—was linked to a large cache of image files discovered by cybersecurity researcher Jeremiah Fowler. Key points typically cited across PetaPixel, Wired coverage referenced therein, and Fowler’s ExpressVPN write-up include:
| Reported detail | Why GRC and security care |
|---|---|
| ~9 million image files (~450 GB) | Scale turns a storage mistake into a mass privacy event |
| Folders resembling “faces” / “profiles” | Suggests biometric-adjacent processing, not one-off uploads |
| No password / encryption on the store (as described) | Classic object-storage misconfiguration pattern |
| URL found via public website code | Discoverability without “hacking” the product UI |
| Adults, teens, and children in sampled images | Heightened duty of care and escalation paths |
| Company dispute that data was “publicly exposed” | Debates over indexing ≠ debates over access controls |
ClarityCheck has disputed characterizations of large-scale public exposure, arguing that access required a specific unindexed URL. From a control-design perspective, that distinction is thin: if a researcher can locate the endpoint from public assets, so can an opportunistic crawler, competitor, or attacker.
For your own program, treat this as a tabletop inject: “Temporary upload storage for identity-adjacent media becomes long-lived, discoverable, and insufficiently locked down.”
Forensic analysis of the exposure
This section is the operational heart of the incident for teams that store user photos, KYC images, support screenshots, or vendor-processed biometrics. You do not need ClarityCheck’s systems to apply the same investigative logic.
1) Frame the hypothesis
Start with a falsifiable statement:
“Object storage holding facial images was reachable without authentication because of misconfigured bucket / object ACLs, public block settings, or a secret-as-URL pattern that leaked into client-side code.”
Then list alternate hypotheses (compromised credentials, overly broad IAM, third-party processor bucket, staging environment left live) so you do not stop at the first narrative.
2) Preserve the evidence set (order of volatility)
Before “fixing” everything in a panic, preserve:
| Artifact | What it answers | Typical owner |
|---|---|---|
| Bucket / container policy & public access block state | Was anonymous GetObject possible? |
Cloud / platform |
| Object ACL samples + encryption settings | Default encryption? SSE-S3 / KMS? | Cloud / platform |
| CloudTrail / storage access logs / CDN logs | Who listed or fetched objects, and when? | Security / IR |
| Client bundle / JS / mobile configs that embed storage hosts | How was the URL discoverable? | AppSec / eng |
| Retention / lifecycle rules + deletion job logs | Did practice match the 14-day (or similar) claim? | Data / eng |
| Data inventory sample (counts by folder, age, content type) | Scope for regulators and customers | Security + Legal |
| Responsible disclosure emails and fix timestamps | MTTD / MTTC narrative for postmortem | Security |
Avoid downloading millions of face images “for analysis.” Prefer metadata inventories, hashed samples under legal guidance, and access-log forensics. Replicating the dataset expands privacy harm.
3) Reconstruct the timeline
Build a minimal timeline even when vendor statements conflict:
- First upload / first object create in the implicated prefix (earliest object timestamp)
- Policy drift moments (when public access became possible)
- URL leak into production client code (deploy history)
- Researcher discovery and disclosure
- Access restriction / remediation complete
- Customer / regulator notifications (if required in your jurisdiction)
If marketing copy says uploads are deleted after N days, compare object ages to that claim. Retention mismatches are both a privacy failure and an audit finding waiting to happen—see ISO 27001 data retention policy.
4) Classify the data
Face photos used for reverse lookup are typically special-category / biometric-adjacent depending on jurisdiction and how they are processed. Classification drives:
- Breach assessment thresholds
- Notification urgency
- Whether “obscure URL” arguments are persuasive to regulators (often they are not)
5) Scope third parties
Fowler noted uncertainty whether storage was operated directly or via a contractor. Your forensic plan should always ask: who owns the account, who has s3:GetObject, and who can change the bucket policy? Vendor-held biometrics belong in vendor risk assessment with contractual deletion SLAs—not trust-me marketing language.
6) Close with control recommendations (not blame theater)
A useful forensic report ends in owners and dates:
- Enforce block public access + deny anonymous reads by default
- Prefer short-lived, authenticated, scoped URLs (or private buckets + app proxies)
- Encrypt with customer-managed keys where appropriate; restrict key admins
- Lifecycle delete or tokenized features instead of raw face archives
- Continuous misconfiguration monitoring mapped to SOC 2 / ISO controls
- Document incident evidence for auditors—see cloud incident response
Forensic checklist for your own environment
Use this as a 48-hour hunt after reading an incident like ClarityCheck:
- Inventory all buckets/containers that store images, KYC packs, chat uploads, or “temporary” media.
- Query for public ACLs, disabled public-access blocks, and anonymous list/get permissions.
- Search production web/mobile artifacts for raw storage hostnames or long-lived tokens.
- Sample object ages vs. published retention windows; open tickets for outliers.
- Confirm access logging is on and retained long enough for investigations.
- Review IAM principals with
s3:*or equivalent wildcards on media prefixes. - Map each store to an owner, data classification, and DPA / subprocessors list.
- Tabletop “researcher finds our upload bucket URL in JS”—measure contain time.
- Attach evidence of checks and remediations to your compliance program (not a private Slack thread).
For AWS-specific hardening patterns, pair this checklist with 21 AWS cloud security strategies and continuous checks via the SecureSlate AWS integration.
Control gaps this incident highlights
| Gap | Failure mode | Stronger pattern |
|---|---|---|
| Security by obscurity | “Unindexed URL” treated as confidentiality | Authenticated access; no anonymous reads |
| Temporary storage without lifecycle | Uploads accumulate for months | Enforced lifecycle + deletion proofs |
| Client-side secret leakage | Storage endpoints in public JS | Backend mediation; short-lived signed URLs |
| Biometric minimization ignored | Raw faces retained “just in case” | Delete raw images; store only what processing needs |
| Vendor assurances without verification | Terms say “permission required” / “private” | Continuous TPRM + technical tests |
| No continuous CSPM | Misconfig discovered by outsiders | Automated public-storage detection |
These gaps map cleanly to SOC 2 security criteria and ISO 27001 Annex A themes around access control, logging, supplier relationships, and information deletion—exactly where compliance programs stall when evidence is screenshot theater instead of live configuration proof.
When biometric storage becomes high risk
| Signal | Risk level | Typical next action | Evidence to keep |
|---|---|---|---|
| Public or anonymous read on media bucket | Critical | Block public access; rotate any leaked URLs; start IR | Policy diff, access logs, fix time |
| Retention exceeds policy / marketing claim | High | Force lifecycle; legal review of over-retention | Lifecycle config + deletion job logs |
| Children / sensitive contexts in uploads | Critical | Escalate to Legal/Privacy; restrict processing | Scope memo, notification decision log |
| Storage owned by unknown subprocessor | High | Contract + technical review; exit if opaque | DPA, SOC report, questionnaire |
| No access logging on biometric stores | High | Enable logging; backfill monitoring | Logging config evidence |
| Only annual cloud review | Medium | Move to continuous misconfig scans | Weekly/continuous check exports |
If two or more High/Critical rows are true, treat the situation as an active exposure program—not a backlog ticket.
Streamline biometric and cloud risk with SecureSlate
Incidents like an exposed facial image database create urgent IR work and lasting audit questions: Who owned the bucket? When did public access open? What retention actually ran? Which vendors touch biometric media? SecureSlate helps security and GRC teams answer those questions with living evidence—not a scramble of screenshots.
Use SecureSlate to:
- Continuously scan for public storage and risky cloud settings with cloud misconfiguration monitoring across AWS, Azure, and GCP
- Map findings to SOC 2 and ISO 27001 controls so remediation becomes audit evidence automatically
- Connect AWS accounts/organizations for read-only posture checks (AWS integration guide)
- Run vendor risk workflows for people-search, KYC, and image processors that handle facial media
- Maintain data retention and incident response policies with attestations, owners, and Data Room evidence
- Track incident timelines, corrective actions, and PBC packages so postmortems survive auditor scrutiny
Get started for free: Create your SecureSlate account
Prefer a walkthrough? Book a demo to align cloud posture, biometric retention, and IR evidence with your frameworks.
FAQ: exposed facial image databases
Is an unindexed cloud URL “secure enough”?
Typically no. Confidentiality should come from authentication, authorization, encryption, and network controls—not from hoping search engines never index a path that appears in public code.
Why are facial images different from other PII?
Faces are durable identifiers. Exposure can enable impersonation, unwanted biometric matching, and long-lived privacy harm that password resets cannot undo.
What should we preserve first in a similar incident?
Bucket/container policies, public-access settings, access logs, client code that embeds storage hosts, retention/lifecycle configs, and disclosure timestamps—before broad deletion that destroys forensic value.
How does this relate to vendor risk?
If a SaaS tool processes photos of people (including people who never consented to your upload), you inherit configuration and retention failures. Assess vendors with technical questions, not brochure claims.
How does SecureSlate help?
SecureSlate connects continuous cloud misconfiguration checks, control mapping, vendor risk, policies, and incident evidence so teams can prevent public-media exposures and prove remediation during audits.
Disclaimer (legal note)
SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney. Descriptions of third-party incidents are based on public reporting and may be disputed by the parties involved; verify primary sources before relying on them for legal or regulatory decisions.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
