We audit NEXIA Switch continuously with our own penetration-testing tool, against an isolated lab server. When we find a hole we close it, verify it and add a regression test that keeps it from coming back — and only then do we publish it here.
Why we tell you this. Security is not proven by saying
“we are secure”, but by showing how we respond. Each entry below is a
problem that no longer exists in your installation, with the date it was closed.
We publish no detail that helps exploit anything: only the what, the fix and the
guarantee that it won't return.
How we handle each finding
| Step | What we do |
|---|---|
| 1 · Finding | We reproduce it in the isolated lab and assign it a severity. |
| 2 · Patch | We fix the root cause, not the symptom. |
| 3 · Regression | We add an automated test or a rule that detects the problem if anyone reintroduces it. |
| 4 · Publication | We document here the what and the fix, with no exploitation recipe. |
Patch log
2026-08-10 · Exposed API schema (medium severity)
- The problem. The OpenAPI document was served without authentication. It leaks no customer data or credentials, but it does leak the full map of API endpoints and parameters — information an attacker uses to prepare an attack. The interactive interface was already disabled; the raw schema was the gap.
- The patch. The route was blocked at the edge, so it returns
404from the internet. The panel and API keep working the same; only the schema exposure was removed. - The regression. The block was baked into the installer, so every new
or updated install is born with the route closed. Our audit tool verifies on
each run that it returns
404.
Think you found a security problem? Write to
support@nexianetworks.com. We answer and, if it applies, you will see it
published here once patched.