Summary
On June 12, 2017 UpGuard analyst Chris Vickery discovered an Amazon S3 bucket owned by Republican data firm Deep Root Analytics that exposed about 1.1 TB of personal data and modeled political preferences on roughly 198 million American voters, and it was secured on June 14, 2017. The exposed records included names, dates of birth, home addresses, phone numbers, voter registration details, party affiliation, and modeled ethnicity and religion linked by 32-character RNC IDs, compiled with contractors TargetPoint and Data Trust. The low-level misconfiguration was that the bucket, reachable at the six-character Amazon subdomain dra-dw, had its access control set to public so anyone could list and download its objects without authentication; the firm said the data was exposed after a settings change on June 1, 2017. This is the canonical example of a large-scale public-read S3 bucket leaking sensitive PII to the open internet.
How to avoid it in your code
- Enable S3 Block Public Access at the account and bucket level so no ACL or policy can make data public.
- Default all bucket ACLs to private and deny anonymous principals in bucket policies.
- Enforce least-privilege IAM policies and require authentication for every object read.
- Use AWS Config and IAM Access Analyzer to detect public-exposure drift and alert immediately.
- Encrypt PII at rest with SSE-KMS and review storage permissions after any settings change.
References
Related vulnerabilities
All Infra →- MEDIUMCLOUD-TOYOTA-2023
On May 12, 2023, Toyota disclosed that a cloud environment managed by its Toyota Connected subsidiary had exposed data on roughly 2.15 million customers, essentially the entire Japanese user base of its T-Connect, G-Link, G-Link Lite, and G-BOOK connected services registered since November 2013. The data was exposed from November 6, 2013 to April 17, 2023, nearly a decade, and included in-vehicle GPS terminal IDs, vehicle chassis numbers, location history with timestamps, and a subset of drive-recorder video footage, but not names, credit cards, or other directly identifying personal data. The root cause was a cloud database misconfigured to be publicly accessible instead of private, attributed to human error during setup and allowing unauthenticated internet access. Toyota cited a lack of active detection mechanisms and insufficient enforcement of data-handling rules, which is why the misconfiguration persisted undetected for years. A follow-up disclosure on May 31, 2023 found additional misconfigured cloud services exposing around 260,000 more customers.
- HIGHCLOUD-BLUEBLEED-2022
On September 24, 2022 SOCRadar discovered a misconfigured Microsoft Azure Blob Storage endpoint that exposed roughly 2.4 TB of business data spanning 65,000+ entities across 111 countries, with files dated from 2017 to August 2022, though Microsoft disputed the entity count as exaggerated. The exposed data included customer names, email addresses, phone numbers, company names, and business transaction documents such as signed invoices, proof-of-execution and statement-of-work files, and product offers. The low-level misconfiguration was that the Blob Storage endpoint's access level was set to allow anonymous public access instead of requiring authentication, so the container and its blobs were readable over the internet without any credential. Microsoft's Security Response Center attributed it to an unintentional misconfiguration on an endpoint not in use and reconfigured it to require authentication, stating it found no indication that accounts or systems were compromised.
- HIGHCLOUD-ACCENTURE-S3-2017
On October 10, 2017, UpGuard publicly disclosed that Accenture had left four Amazon S3 buckets exposed, originally found by researcher Chris Vickery on September 17, 2017. The buckets were named acp-deployment, acpcollector, acp-software, and acp-ssl under the Accenture Cloud Platform prefix, with the largest holding 137GB. They were configured for public access, so anyone who entered or guessed the bucket URL could download the contents with no authentication, and because the S3 subdomain matched the bucket name the names were predictable. Exposed material included a master access key for Accenture's AWS KMS account stored in plaintext, internal Identity API credentials, nearly 40,000 plaintext passwords in a database backup, private signing and decryption keys, certificates, VPN keys, and Google and Azure credentials. The root cause was an S3 public-read misconfiguration: buckets that are private by default had been reconfigured to allow anonymous access, contradicting the secure default.
- HIGHINFRA-USBLITER8-2026
usbliter8, published on 18 June 2026 by a research group called Paradigm Shift, is an unpatchable BootROM exploit for Apple's A12 and A13 chips, the silicon inside the iPhone XS, XR and 11 families plus the Apple Watch Series 4 and 5. It is the long-awaited successor to checkm8, the 2019 exploit that broke every Apple chip from the A5 to the A11 and was assumed to be the end of that road. The bug lives in the SecureROM, the very first code an Apple device runs at power on, which is etched into the silicon at the factory and can never be altered by any software update. usbliter8 abuses a hardware flaw in the Synopsys DWC2 USB controller: a mismatch in how the controller tracks its DMA memory while buffering USB Setup packets lets an attacker walk a write pointer backwards through memory and overwrite arbitrary SRAM, ending in full code execution inside the most trusted code on the chip. From there it can boot unsigned firmware and step outside Apple's chain of trust entirely, stamping the string PWND into the device's USB serial number as proof of control. The catch is that it is not a remote attack: it needs physical possession of the device, DFU recovery mode, a USB connection and a small RP2350 microcontroller board, and nothing it changes survives a reboot. It also does not break the Secure Enclave, so a device protected by a strong passcode keeps its user data encrypted even after the boot chain has been taken over. Apple cannot repair the affected chips; the only real remedy is newer hardware, because the A14 and later configure the controller correctly and are out of reach.
- HIGHCVE-2026-31431
Copy Fail (CVE-2026-31431), disclosed on 29 April 2026 by the security firm Theori, is a Linux kernel flaw that turns any unprivileged local user into root with a 732-byte Python script and no luck required. Despite a name that sounds like a clipboard bug, it has nothing to do with copy and paste: it is a failed copy deep in the kernel's crypto code. A nine-year-old optimization in the AF_ALG crypto socket interface let an attacker steer the kernel into writing four attacker-chosen bytes into the page cache, the in-memory copy of files that the CPU actually executes. Patch the cached pages of a setuid-root binary like /usr/bin/su, run it, and you are root. The exploit is a straight-line logic flaw with no race condition and no hardcoded kernel addresses, so the exact same script runs at roughly 100 percent reliability across Ubuntu, RHEL, SUSE, Amazon Linux and every other distribution built since 2017. Worse, because the page cache is shared by the whole machine, it crosses container boundaries: one poisoned page in a Kubernetes pod can compromise neighbouring tenants and the host. The disk file is never touched, so file-integrity scanners stay silent. It rates CVSS 7.8 (High), was added to CISA's Known Exploited Vulnerabilities catalog on 1 May 2026, and is notable for how it was found: an AI-assisted code scan surfaced a bug that had been silently exploitable for nearly a decade in about one hour.
- CRITICALCVE-2025-1974
IngressNightmare was a chain of five vulnerabilities in the Ingress-NGINX Controller for Kubernetes disclosed on 24 March 2025 by the Wiz Research team, the most severe being CVE-2025-1974 (CVSS 9.8), which enabled unauthenticated remote code execution from the pod network. Wiz estimated about 43% of cloud environments were vulnerable and identified over 6,500 publicly exposed clusters, including Fortune 500 organizations. The controller's validating admission webhook ran as an unauthenticated HTTP endpoint reachable by any workload on the pod network, accepting attacker-supplied AdmissionReview requests containing crafted Ingress objects. The supporting CVEs (CVE-2025-24514 auth-url, CVE-2025-1097 auth-tls-match-cn, CVE-2025-1098 mirror UID, CVE-2025-24513 path bypass) injected unsanitized NGINX configuration directives via annotations into a temporary config the controller validated with nginx -t. The attacker uploaded a shared-library payload by abusing NGINX client-body buffering (an oversized Content-Length keeps the request file descriptor open in ProcFS) and then used the injected ssl_engine directive to load that library during validation, achieving code execution in the controller pod whose service account could read all cluster secrets across namespaces, enabling full cluster takeover.