Some vulnerabilities are subtle. A misconfigured JWT, a complex rate-limit bypass, a leaky S3 bucket buried in an obscure subdirectory.
This is not one of those stories.
This is a story about a company backed by Andreessen Horowitz, holding active Department of Defense contracts, that had essentially no authorization on its API.
With an ordinary account, Strix was able to access users, organizations, courses, training metadata, and direct document links across tenants. The exposed data included U.S. service member records and sensitive military training materials.
Update: On May 1, 2026, after 150 days from our initial disclosure, Schemata responded, acknowledged that the affected endpoints were exposed, and said they would patch the issue immediately. We verified remediation before publishing. We are glad the issue is now fixed.
What Schemata Does
Schemata is an AI-powered virtual training platform for the military and defense sector. Think immersive 3D simulations for naval personnel, Army grenadiers, Air Force operators, and defense contractors. They have received millions in government contracts and handle highly sensitive operational training data.
How Strix Found It
We have been building Strix, an open-source autonomous AI hacking agent that dynamically tests applications, validates vulnerabilities through real exploitation, and produces working proof-of-concept reports. We recently crossed 24,000 GitHub stars and run thousands of scans a day.
We heard about Schemata and assumed that, as a DoD contractor handling military training data, it would be a useful benchmark for the latest version of Strix. The target looked exactly like the kind of system where authorization boundaries should be boring, robust, and strict.
So we pointed Strix at the application.
The first step was not clever. Strix established a low-privilege baseline, watched the browser traffic, and mapped the reachable API surface from normal application behavior and client-side route references. Then it replayed the highest-value collection endpoints with that same ordinary session.
That was enough.
The API was not just returning data for its account or my organization. It was returning data across the platform. There was no meaningful organization scoping, no tenant isolation, and no permission check preventing a low-privilege user from accessing other organizations' records.
With only the session from the unprivileged test account, Strix could access:
- The entire user base: a user listing endpoint returned names, emails, enrollment data, and specifically which military bases U.S. service members were stationed at.
- Hundreds of confidential training manuals: course and organization listing endpoints exposed metadata and direct AWS S3 links for their library of sensitive military operations modules.
- Write-enabled routes: The lack of authorization checks meant a malicious actor could potentially modify or delete courses entirely using update or delete requests.
Screenshots are redacted to remove bearer tokens, personal records, direct document paths, object identifiers, and other sensitive values.
At first, we did not fully understand how bad the exposure was. Seeing broad API responses is one thing. Seeing what those objects actually represented was different.
A sampling of what was sitting there:
- A 3D virtual training course for naval maintenance personnel, featuring documentation explicitly marked confidential and proprietary.
- A training course containing Army field manuals on the safe handling, arming sequences, and tactical deployment of explosive ordnance.
- Hundreds of user records documenting the bases, emails, and full names of active U.S. service members, many of whom were enrolled in specific training courses that could be used to infer their roles and responsibilities.
Our Efforts To Disclose
We immediately stopped testing and tried to disclose the vulnerability privately. The goal is always a patch.
The timeline:
- December 2, 2025 - First contact with Schemata. Their initial reply from the CEO: "I would love to hear what the vulnerability is, but I assume you want to get paid for it. Is that the play?"
- December 2, 2025 - We clarified that compensation was not required and that our priority was the safety of their users. We asked for the appropriate channel to send the details.
- December 8, 2025 to December 29, 2025 - We sent multiple follow-up emails warning that the vulnerability was critical and could be actively exploited, eventually looping in additional team members. We repeatedly asked where to send the report.
- January 27, 2026 - We independently verified that the vulnerability was still live.
- May 1, 2026 - We sent a final follow-up explaining that we were preparing to publish. Schemata responded, acknowledged that the affected endpoints were exposed, and said they would patch the issue immediately.
- May 3, 2026 - Publishing after remediation, 152 days after initial disclosure.
The final outcome is good: Schemata acknowledged the issue and fixed it before publication. But the disclosure process still matters. For five months, a critical vulnerability affecting defense-sector users remained unresolved despite repeated private attempts to get it in front of the right people.
We are publishing this for one reason: the users and customers affected by this exposure deserve enough information to protect themselves and ask the right questions. This should not become a reason to attack Schemata; that only teaches companies to hide security failures instead of fixing them. The lesson is that having open disclosure channels, robust authorization testing, and incident response preparation need to be priorities for all teams, especially those handling sensitive data.
Why This Matters Beyond Schemata
Schemata holds active DoD contracts. Under federal regulations, specifically DFARS 252.204-7012 and related CMMC requirements, contractors handling Controlled Unclassified Information (CUI) have mandatory cybersecurity and breach-reporting obligations.
A platform serving military training data with literally no authorization layer on its API is a foundational failure and a massive OPSEC risk. At Strix we are not lawyers, but we would be surprised if this does not constitute a reportable incident. The virtually non-existent anonymization of the user data alone leaves U.S. service members highly vulnerable to targeted phishing or doxing.
If someone had malicious intent, they would not need source code, privileged credentials, or an insider account. A normal account was enough to enumerate users, infer military affiliations and training assignments, and access sensitive course metadata and documents. That is the part that should worry every organization building software for government and defense customers.
What You Should Do
If you are a Schemata customer or partner, particularly in the defense or government space, you should be asking Schemata directly what data was accessible, for how long it was exposed, whether access logs were reviewed, and whether affected users and customers were notified.
If you are a developer, this is a reminder that authorization is not optional. It is the most basic layer of any multi-tenant application. Strix caught this in a first pass. If your platform handles sensitive data, you should be running continuous, automated security validation before bad actors do it for you.
If you are building a company, consider that not responding to a security researcher is not a neutral act. It is a decision that leaves your users exposed. The researchers who email you are trying to help.