UpGuard identified a publicly accessible AWS S3 repository operated by NICE Systems, a Verizon third-party vendor, that exposed customer call-centre logs containing names, addresses, phone numbers, account details and some unmasked Verizon account PINs.
The incident is a clear example of third-party cloud risk becoming enterprise risk: Verizon customer data was exposed through vendor-controlled infrastructure, not Verizon-owned systems. The source material shows a basic but high-impact control failure-sensitive data stored in an internet-accessible S3 bucket that was fully downloadable by URL, with inconsistent masking of sensitive fields and a delayed remediation window between notification and closure. The broader lesson is architectural as much as procedural: public cloud storage mechanisms designed for openly accessible content should not be used for private customer data, especially where known discovery methods and commodity scanning make exposed buckets easy to find. For cloud security and governance teams, this maps directly to failures in storage configuration, vendor oversight, sensitive data handling and detection coverage for public exposure of regulated or high-risk customer authentication data.
| What’s happening | Cause | Action |
|---|---|---|
| Sensitive Verizon customer data was stored in a publicly accessible AWS S3 repository | UpGuard reports the NICE Systems bucket was “fully downloadable and configured to allow public access,” allowing access by entering the S3 URL. The commentary further highlights misuse of internet-facing S3 functionality intended for public content, not private customer data. | Validate that no buckets containing customer, call-centre, identity or authentication data allow anonymous access, public ACLs, public bucket policies or public website-style exposure. SkySiege would assess S3 public exposure paths, internet-reachable storage configurations, bucket policy posture and whether sensitive datasets are placed in storage architectures intended for public distribution. |
| The storage architecture made discovery easy, not just access easy | The repository was reachable through a known AWS S3 addressing pattern and named “verizon-sftp,” making it identifiable. The commentary stresses that exposed S3 endpoints are routinely scanned using known tooling and naming enumeration. | Validate whether cloud storage naming, DNS exposure and service endpoint usage create low-effort discovery paths for attackers. SkySiege would assess externally discoverable storage assets, naming leakage, known public endpoint usage and whether sensitive repositories are exposed through commonly scanned cloud service patterns. |
| Authentication-related data was exposed, creating account takeover risk | Source content confirms some records included unmasked Verizon account PINs alongside phone numbers and other customer information. Those PINs were used to verify callers, making impersonation and SIM-swap style abuse plausible. | Validate whether authentication secrets, PINs, call-centre verification data or support-channel identity attributes are stored in logs and whether masking is consistently enforced. SkySiege would assess exposure of secrets and verification data in cloud storage, identify unmasked sensitive fields and flag datasets that materially increase account takeover risk. |
| Data protection controls were inconsistently applied | UpGuard observed many records with masked sensitive fields, but also records where no masking existed, including thousands of unmasked PINs in one text file. This indicates broken or inconsistent data handling controls rather than a one-off file anomaly. | Validate data classification, masking, tokenization and log-sanitization controls across all ingestion and export paths. SkySiege would assess whether sensitive fields appear in raw logs, whether masking controls are partial or inconsistent and whether storage contains mixed protected/unprotected records that indicate control failure. |
| Vendor data segregation appears weak | The same repository also contained internal data from Orange S.A., another NICE Systems partner. Even if that data appeared less sensitive, the co-location of multiple customers’ data in one exposed repository indicates poor tenant separation and governance. | Validate logical and physical segregation between customer datasets in vendor-managed environments. SkySiege would assess cross-client data commingling, shared storage patterns and whether third-party architectures create multi-customer blast radius in the event of a single exposure. |
| Remediation and escalation took too long for an internet-exposed dataset | UpGuard says Verizon was notified on June 13 and the exposure was closed on June 22. For publicly downloadable customer data, that delay extended the period in which unauthorised access could occur. | Validate incident routing, vendor notification SLAs and emergency response authority for third-party cloud exposures. SkySiege would assess whether vendors with sensitive data are governed by measurable remediation timelines, whether public exposure paths are continuously monitored and whether ownership for rapid containment is clear. |
| Third-party access to sensitive customer data outpaced oversight | NICE Systems was a trusted Verizon partner supporting call-centre and back-office operations, yet the exposed data sat in vendor-controlled AWS infrastructure. The source material explicitly frames this as third-party vendor risk becoming direct business risk. | Validate which vendors store or process customer PII, support-channel data and verification secrets in their own cloud accounts. SkySiege would assess third-party cloud footprint risk, sensitive data residency outside the enterprise boundary and whether vendor security controls match the criticality of the data entrusted to them. |
This incident was not just a storage misconfiguration; it was a failure in cloud architecture, vendor governance and detection coverage. Sensitive customer support data was placed in a cloud repository that UpGuard could access anonymously over the internet and the commentary correctly emphasises the significance of using a public-access storage pattern that is inherently easy to scan and enumerate. That turns a private data handling requirement into an exposure model optimised for discovery.
The business impact extends beyond privacy loss. Unmasked Verizon account PINs materially increased the likelihood of customer impersonation, call-centre fraud, account changes and SIM-swap style attacks. Because mobile numbers often underpin SMS-based authentication, the operational consequence can expand from telecom account abuse into downstream compromise of consumer accounts protected by text or voice verification.
There are also clear visibility and governance gaps. Verizon’s customer risk depended on NICE Systems’ AWS controls, but the source material gives no indication that those controls prevented public exposure or enforced consistent masking. The inclusion of Orange data in the same repository suggests weak customer segregation and raises broader concerns around data handling discipline inside vendor-managed environments.
From an enterprise risk standpoint, this creates financial exposure through incident response, customer notification, fraud losses, contractual disputes and potential regulatory scrutiny tied to handling of personal data and authentication information. Reputationally, customers do not distinguish between enterprise and vendor custody; if a trusted partner exposes data, the brand owner absorbs the damage. For cloud security teams, the lasting lesson is clear: public storage exposure, especially in third-party environments, must be continuously detected, governed and treated as a direct business-critical control failure.
