2.3 million subscribers (with 40 million more threatened)
On December 29, 2025, it was confirmed that a threat actor using the alias "Lovely" leaked a database of 2.3 million WIRED magazine subscribers on a hacking forum. The actor claims the data leak is a direct result of parent company Condé Nast ignoring responsible disclosure attempts regarding security vulnerabilities for over a month. The leaked data contains 2,366,576 records, including unique email addresses, user IDs, and for a subset of users, more sensitive PII like full names, phone numbers, and mailing addresses. The threat actor has further threatened to release an additional 40 million records allegedly stolen from other high-profile Condé Nast brands, including The New Yorker, Vogue, and Vanity Fair. The incident highlights the risks of ignoring security researcher outreach and the potential for reputational damage and widespread data exposure.
The threat actor, "Lovely," appears to have transitioned from a gray-hat security researcher to a black-hat data extortionist. After their attempts to report vulnerabilities to Condé Nast were allegedly ignored, they chose to weaponize their findings by leaking the data publicly.
The Leaked Data:
The Threat:
Security researchers analyzing the incident believe the attacker likely exploited common web application vulnerabilities. The most probable attack vectors are:
T1087) The attacker may have found a way to access user records by manipulating a user ID parameter in a URL or API call (e.g., changing ?user_id=123 to ?user_id=124) without proper authorization checks.T1098) The application may have had endpoints that exposed user data without verifying that the requester was an authenticated and authorized administrator.The attacker likely wrote a script to iterate through user IDs or other identifiers to scrape the entire database over time (T1119). The wide range of timestamps in the data suggests access to a production or archival database rather than just a front-end system.
Detection:
Response:
security@ email address, a bug bounty program).M1053) Establishing a formal, well-publicized VDP or bug bounty program provides a constructive channel for researchers like "Lovely" to report findings. This turns potential adversaries into allies and allows the company to fix flaws before they are exploited or publicly disclosed.M1013) Developers must be trained in secure coding practices to prevent common vulnerabilities like IDOR and broken access control. All code should be subject to security reviews and static/dynamic analysis (SAST/DAST) before deployment.Training developers on secure coding practices to prevent common web vulnerabilities like Insecure Direct Object Reference (IDOR).
Establishing a clear and responsive channel for security researchers to report vulnerabilities, preventing them from resorting to public disclosure.
Properly configuring web applications and APIs to enforce strict access control on every request for sensitive data.
Mapped D3FEND Techniques:
The root cause of this public data leak, according to the attacker, was the lack of a responsive channel for reporting security flaws. The most effective countermeasure for Condé Nast and other large organizations is to implement a formal, public, and well-managed Vulnerability Disclosure Program (VDP). This involves creating a dedicated security.txt file, a clear policy page on their website, and a monitored inbox (e.g., security@condenast.com). A VDP provides a safe harbor for researchers and a structured process for intake, triage, and remediation of vulnerabilities. By engaging with the security community constructively, companies can turn potential adversaries into allies, fix bugs before they are exploited, and avoid the reputational and financial damage of a public breach like this one.
To prevent the mass data scraping that led to this breach, Condé Nast should implement robust access pattern analysis on its user-facing APIs and applications. This defense focuses on detecting and blocking the automated techniques used to exploit IDOR or broken access control flaws. The system should be configured to detect and alert on anomalous behavior, such as a single IP address or API key making thousands of sequential requests to a user profile endpoint (e.g., api.wired.com/users/1, api.wired.com/users/2, etc.). Upon detecting such a pattern, the system should automatically apply temporary blocks or stricter rate limits to the offending source, effectively stopping the data exfiltration in its tracks. This moves beyond simple rate limiting to intelligent, behavior-based blocking.
The core technical failure appears to be in the application's authorization logic. Application hardening must be a priority. This requires a shift-left security approach where developers are trained to never trust user-supplied input. Every single API endpoint or web page that accesses a user's data must re-validate the session token or API key to ensure the requester is authorized to view that specific data object. For example, when a user requests users/123, the backend code must not only check if the user is logged in, but also verify that the logged-in user's ID is 123. This practice of centralized, mandatory access control checks, enforced by the application framework, is the fundamental defense against IDOR vulnerabilities.

Cybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Help others stay informed about cybersecurity threats