CVE-2026-92604 is an arbitrary file write in Scirius through version 3.8.0, a web application for managing Suricata rules. A user with the default User role can write files with a .json extension to paths of their choice. NVD scores it High (8.1). We could not confirm a fix.
What's affected
The NVD record lists Scirius through 3.8.0 as affected. The reporter's public write-up says it was validated against the project's code at the time of 3.8.0 and that the endpoint is protected only by a permission that every non-administrative user holds by default.
The weakness is CWE-22, path traversal. The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H.
We found no fixed version. The disclosure timeline in the write-up says the report was sent in June 2026, followed up in August, and published in September after no response from the project. Check the Scirius repository for any release or commit after 3.8.0 before relying on this, and treat it as unpatched until you confirm.
How to check if you're exposed
Find the Scirius version you run. If you deploy it as part of a larger Suricata stack, such as a packaged distribution, check that product's own version notes too.
Then list the accounts that have the default User role. The attacker in this write-up is an ordinary logged-in user, so every account counts. Also check how the application runs. The report says the official container setup has no non-root user, so the service runs as root in that configuration, which raises the effect of any file write.
Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.
What to do now
- Limit Scirius accounts to people who need them and remove stale ones.
- Keep the web interface and API off untrusted networks.
- Run the service as an unprivileged user with a read-only filesystem except for its data paths. This limits what a file write can reach.
- Watch the project repository for a fix and apply it as soon as one is released.
- Check for unexpected JSON files in system directories if you have run an affected version with many users.
Why it matters
The write-up says the upload handler takes a name from a field inside the uploaded document and joins it to a base directory without cleaning it. Names containing parent-directory sequences then point outside the intended folder. The file content is also controlled by the user, so the write is not just a nuisance.
The risk is raised by two facts from the report. The permission needed is held by default users, and the official container runs as root. That combination turns a path bug into a way to place files in sensitive locations. The KEV flag in the record is false and no source we read reports exploitation.
Quick check
Is there a fix?
We could not confirm one. The disclosure says the project had not responded when it was published.
Why does running as root matter?
The write is done with the service's rights, so a root process can place files anywhere on the system.
Sources
Last reviewed: 18 October 2026.
