Safeguard
Vulnerability Analysis•

CVE-2023-7210: High Improper Authentication in OneNav

CVE-2023-7210 is a high (CVSS 7.3) improper authentication bug in the OneNav API through version 0.9.33. Check for a newer release and restrict access.

Safeguard Security Team
3 min read

CVE-2023-7210 is an improper authentication flaw in the API of OneNav up to version 0.9.33. It scores 7.3 (High). The record and the GitHub advisory do not name a patched version, so check the project for a newer release and limit who can reach the API.

What's affected

Affected: OneNav up to and including 0.9.33. The affected component is the API at /index.php?c=api, and the argument is the X-Token header.

Fixed: unknown. The GitHub Advisory Database entry (GHSA-353q-7h99-hf4x) lists the affected and patched versions as unknown and has no package mapped. Check the OneNav project for releases after 0.9.33.

The vector is network reachable, no privileges, no user interaction, with low impact on confidentiality, integrity and availability. The weakness is CWE-287, improper authentication. The record says the exploit has been disclosed publicly. KEV is false.

How to check if you're exposed

OneNav is a self-hosted web app, so check your own install. The version is usually shown in the admin area or in the project's files. Anything at 0.9.33 or earlier is in range.

If you cannot reach the version, check whether the API path is publicly reachable by looking at your web server access log for requests to the api route.

What to do now

  1. Upgrade OneNav to a release newer than 0.9.33 if the project has published one, and read its notes for an authentication fix.
  2. Put the application behind a login at the web server, a VPN, or an IP allow list, so the API is not reachable by everyone.
  3. Review the data stored in the app for unexpected changes and reset any tokens or passwords you use with it.
  4. Limit what the app stores. A bookmark manager should not hold secrets.

Why it matters

Improper authentication means the application accepts a request as legitimate when the proof it was given should not be enough. In an API, that proof is often a token header. If the check on that header can be bypassed, the caller acts as an authorized user.

The score is not extreme because the scored impact is low across the board. Still, an exposed API with weak checks tends to be found by automated scanning quickly once details are public. If you run OneNav for a team, assume the API has been probed and check for entries you did not add.

Quick check

Is there a fixed version of OneNav?

Not named in the record or the GitHub advisory, which lists patched versions as unknown. Check the project's releases.

What is the weakness?

Improper authentication in the API, tied to how the X-Token header is handled.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.