Trend Research discovered that the AI photo-editing app Wondershare RepairIt stored thousands of user images in an unsecured cloud bucket and embedded overly permissive access credentials inside its binary. That mistake exposed private photos and downloadable AI models — a dangerous combination that can enable model tampering and software supply-chain attacks. The issues were reported through Trend ZDI and assigned CVE-2025-10643 / CVE-2025-10644.
Researchers at Trend analyzed the RepairIt client binary and found hardcoded cloud storage credentials (read/write) that pointed to an unencrypted object storage bucket. That bucket contained:
- Thousands of user-uploaded photos and videos (some sensitive), retained for up to two years
- AI model packages that the app downloads and executes locally
- Signed application executables, container images, and other internal artifacts
Because the app automatically downloads and runs models from that same bucket, an attacker who could write to the bucket might substitute malicious or trojanized models — effectively turning a single credential leak into a far-reaching supply-chain compromise.
Why this is more than a privacy incident
At first glance this looks like a classic privacy failure: a service claiming not to retain user data was actually storing unencrypted user files. But the security implications run deeper:
- Model tampering risk: Locally executed AI models are a new attack surface. If an attacker replaces or modifies a model, they can change outputs, exfiltrate data, or execute code on client machines.
- Supply-chain danger: The bucket stored vendor-signed binaries and images. Compromising those files could allow malicious payloads to be distributed through legitimate update channels.
- Regulatory exposure: The retention of unencrypted personal data raises GDPR, HIPAA and other compliance red flags — including potential fines and mandated breach disclosures.
How this typically happens (and why it’s preventable)
Several familiar failures combined here:
- Hardcoded credentials in distributed binaries — a convenience pattern that hands attackers the keys if they reverse-engineer the executable.
- Overly permissive tokens that allow read/write rather than write-only telemetry or scoped downloads.
- Unencrypted storage and poor access controls on cloud buckets.
- Absent DevSecOps controls — no automated secret scanning, no model integrity checks, and no content signing/verification at runtime.
Lessons learned — practical mitigation steps
Organizations shipping AI-enabled apps should treat model delivery and cloud credentials as first-class security risks. Key countermeasures include:
- Never embed secrets in binaries. Use short-lived, tightly scoped tokens issued at runtime via an authenticated backend or managed identity.
- Follow least privilege. Ensure tokens used by clients are write-only (for telemetry) or read-only for specific model files, and cannot list or modify other bucket contents.
- Model signing & verification. Sign model artifacts server-side and verify signatures before loading or executing models locally.
- Encrypt at rest and in transit. Use server-side encryption and HTTPS with strict certificate pinning where feasible.
- DevSecOps tooling. Integrate secret-scaners into CI/CD, run regular binary analysis, and automate detection of embedded credentials.
- Supply-chain hardening. Apply reproducible builds, supply-chain provenance, and multi-party attestations for distributed binaries and containers.
- Incident response & disclosure. Have a plan for quick rotation of compromised keys, revoke stale credentials, and notify affected users and regulators promptly.
Broader implications for AI and software security
This incident is a useful case study in why AI changes the risk model for software vendors and users alike. Unlike typical web services, AI apps often:
- Download or execute complex models locally, which widens the attack surface beyond server-side code.
- Process sensitive personal content (images, audio) that can have higher privacy impact if leaked.
- Introduce a new integrity requirement: models must be trusted artifacts, not mutable blobs that anyone with write access can swap.
As AI adoption grows, regulators and enterprise buyers will increasingly demand demonstrable model integrity and stronger DevSecOps practices — not just promises in privacy policies.
What users and admins should do now
- Users: If you used the affected app, assume content might have been stored. Review the vendor’s disclosure, change linked passwords, and avoid uploading highly sensitive content until the vendor demonstrates fixes.
- IT admins / security teams: Block or sandbox suspicious versions, scan endpoints for the app’s presence, and monitor outbound calls to unknown storage endpoints. Enforce endpoint protection and network egress rules for model downloads.
- Product teams: Treat model distribution like firmware updates — require signed artifacts, integrity checks, and short-lived credentials for any runtime downloads.
Final take — trust requires proof
Trend’s disclosure (CVE-2025-10643 / CVE-2025-10644) is a reminder that privacy statements mean little without secure architecture and rigorous DevSecOps. AI increases both the value of data and the impact of compromise. Vendors must adopt proven controls — secret management, model signing, encrypted storage, and continuous binary analysis — to prevent leaks and stop single points of failure from cascading into global supply-chain incidents.
Need a quick checklist? Start by scanning your binaries for embedded secrets, rotate any long-lived cloud tokens, sign your model artifacts, and add model-validation into your client startup path. Want a template checklist to share with your engineering team? Reply and I’ll draft one you can paste into your internal wiki. Have thoughts or first-hand info about this incident? Share them below — community input helps improve security for everyone.
