Reported: March 20th 2026
Affected Product: https://www.lastepochtools.com/ (Build Planner / Data Section)
Vulnerability Type: Information Disclosure (CWE-200)
Severity: High
CVSS v3.1 Score: 7.5
CVSS Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Summary
The website loads its entire Last Epoch item database (itemDB) into client-side JavaScript memory on the Build Planner page. Any visitor can instantly extract the complete dataset (including every unique item, affix, stat, and internal identifier) via the browser console. No authentication, rate limiting, or server-side protection is present. This constitutes a complete data exfiltration vulnerability.
Technical Details
When a user navigates to the Build section, the site performs a full client-side load of the database into a global JavaScript object named itemDB. This object is directly accessible from the developer console and contains the complete, unredacted dataset used by the site.
When looking, ALL of the data for Last Epoch is located in this object. Here is an example of a Unique item from Last Epoch
Extracting this information from the web-browser to a JSON text string is trivial using this command:
Proof of Concept (PoC)
1: Navigate to https://www.lastepochtools.com/builds/
2: Open the browser developer console as Admin (F12).
3: Type or paste the following one-line command:
copy(JSON.stringify(itemDB));
4: The entire database is instantly converted to JSON and copied to the clipboard.
5: Paste the clipboard contents into a file (itemDB.json) and import directly into any NoSQL database, spreadsheet, or custom tool.
This process takes literally seconds and requires zero credentials or special tools.
In order to get a complete idea of the item, the relationship between the item data and the strings are located here:
https://www.lastepochtools.com/data/version140/i18n/full/en.json
The property name is the key to the string in the en.json
Impact
- Complete loss of data confidentiality for the entire Last Epoch dataset maintained by the site.
- Competitors, scrapers, or malicious actors can mirror the full database with trivial effort.
- Bypasses any intended effort, licensing, or business value invested in compiling/maintaining the dataset.
- No server logs or rate limiting are triggered, making the exfiltration completely silent.
Recommended Mitigation and Remediation
Immediate Action (High Priority): Remove the full client-side itemDB object. Do not ship the entire database to the browser.
Long-Term Remediation (Recommended):
- Adopt a server-side rendered or API-driven architecture (e.g., Next.js SSR, Express/Node API, or similar).
- Serve only the data required for the current view or query via authenticated, rate-limited API endpoints (e.g., /api/items?type=unique&id=123).
- Implement proper backend access controls:
- Rate limiting per IP/session
- Optional API keys or CAPTCHA for bulk access
- Server-side pagination and filtering
- If partial client-side caching is required, use obfuscated/minified data structures that do not expose the full schema or internal identifiers.
- Consider moving high-value static data behind a protected backend or using a CDN with access tokens instead of exposing raw objects.
These changes align with standard secure web application design and will prevent both accidental and intentional data exfiltration while maintaining full functionality for legitimate users.
The site owner is strongly encouraged to implement the above remediation as soon as possible. Once fixed, the vulnerability should be re-verified by attempting the PoC command and confirming the itemDB object no longer exists or contains only minimal/necessary data.
Responsible Disclosure Note This disclosure is published publicly to ensure rapid awareness and remediation. The site owner may contact the researcher for coordinated disclosure or verification if desired.
Author Comment
I could make a joke about Diablo 3/4 loading everyone’s inventory into memory of everyone in the same instance but lets keep it friendly.
Leave a Reply